<HTML>
<HEAD>
<title> rel4.4 </title>
</HEAD>
<BODY  bgcolor="#ffffff"  text="#000000">

<center>
<h1> rel4.4 </h1>
</center>

<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa12786; 2 Nov 91 4:23 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa13401; 2 Nov 91 3:26 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa13393; 2 Nov 91 3:20 EST
Date:     Sat, 2 Nov 91 3:12:23 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  errata4.0-sun-xgl
Message-ID:  &lt;9111020312.aa12249@WOLF.BRL.MIL&gt;

<p>
This is a minor change to make mged/dm-xgl.c compile on a Sun
workstation with XGL. XGL is an add-on product for the Sun, desirable
primarily if you have a Sun GX hardware graphics processor.  Unless you
have added dm-xgl to your MGED configuration, you do not need this fix.

<p>
Thanks to the folks at U.S. Army MICOM for contributing the dm-xgl.c
module. This error is entirely my fault, it crept in when I converted
their code to use the new "chunky" vlist structures.  Since BRL does not
have a copy of XGL, the modifications could not be tested. Thanks to
David Turner of Sandia National Labs for pointing out the error, and
debugging with me via "remote control" on the telephone one long
afternoon.

<p>
	Best,
	 -Mike

<p>
923,925c923,925
&lt; 					ptr-&gt;x = pt[0];
&lt; 					ptr-&gt;y = pt[1];
&lt; 					ptr-&gt;z = pt[2];
---
&gt; 					ptr-&gt;x = pt[0][0];
&gt; 					ptr-&gt;y = pt[0][1];
&gt; 					ptr-&gt;z = pt[0][2];
932,934c932,934
&lt; 					ptr-&gt;x = pt[0];
&lt; 					ptr-&gt;y = pt[1];
&lt; 					ptr-&gt;z = pt[2];
---
&gt; 					ptr-&gt;x = pt[0][0];
&gt; 					ptr-&gt;y = pt[0][1];
&gt; 					ptr-&gt;z = pt[0][2];
<hr>
<hr>
Date:     Wed, 18 Dec 91 8:08:05 EST
From:     Mike Muuss  &lt;mike@brl&gt;
To:       ACST@BRL.MIL
Subject:  mged pr_solid() eliminated
Message-ID:  &lt;9112180808.aa16391@WOLF.BRL.MIL&gt;

<p>
Inside MGED, I have eliminated the subroutine pr_solid(), and replaced it
with a new one that uses import/export ft_describe() interface instead.
This is an important step in the cleanup of solid editing.
	-Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa13029; 13 Nov 91 19:57 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa11366; 13 Nov 91 19:54 EST
Date:     Wed, 13 Nov 91 19:35:21 EST
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
To:       Tng Tai Hou &lt;taihou@iss.nus.sg&gt;
cc:       cad@BRL.MIL
Subject:  Re:  BRL for Sparc with X11R4, not OW
Organization:  Doubly-Linked_List
Message-ID:  &lt;9111131935.aa11253@VMB.BRL.MIL&gt;

<p>
&gt;I am not much of a hacker, but I need to compile BRLCAD on
&gt;my Sparc 1+ running the MIT's X11R4, not OpenWindows.

<p>
In Cakefile.defs, change these two lines:
#       define  sun_no_opts     /* Production configuration */
#       undef   sun_x11

<p>
to these two lines:
#       undef  sun_no_opts     /* Production configuration */
#       define   sun_x11

<p>
If your X11 software is not in /usr/X11 (/usr/X11/include, /usr/X11/lib) then
you will need to modify the following section to reflect where the include
files and libraries are located:

<p>
#       ifdef sun_x11
/*              Sun with X11 configuration */
#               define  LIBFB_OBJS      if_remote if_ab if_sun if_X
#               define  LIBFB_CONFIG    -DIF_REMOTE -DIF_AB -DIF_SUN \
                        -I/usr/X11/include -DIF_X
#               define  LIBFB_LIBES     LIBPKG -lsuntool -lsunwindow -lpixrect \
                        -L/usr/X11/lib -lX11
#               define  MGED_OBJS       dm-sun dm-X
#               define  MGED_CONFIG     -DDM_SUNPW -DDM_X -I/usr/X11/include
#               define  MGED_LIBES      -lsuntool -lsunwindow -lpixrect \
                        -L/usr/X11/lib -lX11
#       endif

<p>

<p>
Lee A. Butler
Ballistic Research Laboratory		Internet: butler@brl.mil
Aberdeen P.G., MD 21005-5066		Phone: (301) 278-9200

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa13340; 13 Nov 91 21:13 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa11836; 13 Nov 91 21:02 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa11822; 13 Nov 91 20:55 EST
Date:     Wed, 13 Nov 91 20:45:26 EST
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
To:       cad@BRL.MIL
Subject:  4.0 errata
Organization:  Doubly-Linked_List
Message-ID:  &lt;9111132045.aa13281@WOLF.BRL.MIL&gt;

<p>
There is a bug in the "pixscale" utility as distributed under 4.0 which causes
it to dump core.  The following patch should correct the problem.

<p>
155,156c155,156
&lt;       if (inx &lt; outx) i = outx;
&lt;       else i = inx;
---
&gt;       if (inx &lt; outx) i = outx * 3;
&gt;       else i = inx * 3;

<p>
Lee A. Butler
Ballistic Research Laboratory		Internet: butler@brl.mil
Aberdeen P.G., MD 21005-5066		Phone: (301) 278-9200

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa21826; 15 Nov 91 12:40 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa01182; 15 Nov 91 12:35 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa00985; 15 Nov 91 12:11 EST
Date:     Fri, 15 Nov 91 12:06:16 EST
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
To:       cad@BRL.MIL
Subject:  Patch to fbserv.c
Organization:  Doubly-Linked_List
Message-ID:  &lt;9111151206.aa21651@WOLF.BRL.MIL&gt;

<p>
There is a bug in "fbserv" as distributed under 4.0 which causes a problem
when used as a "lingering" window on some systems.  Lingering windows which
have been dismissed will disappear, but the process remains and consumes
non-tirvial amounts of CPU time until the user logs out.  The following patch
to "fbserv.c" in the fbserv directory will fix this problem.

<p>
370a371,372
&gt;                       else
&gt;                               break;

<p>
Lee A. Butler
Ballistic Research Laboratory		Internet: butler@brl.mil
Aberdeen P.G., MD 21005-5066		Phone: (301) 278-9200

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa02951; 20 Dec 91 21:10 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa11959; 20 Dec 91 20:33 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa11887; 20 Dec 91 20:25 EST
Date:     Fri, 20 Dec 91 20:18:30 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       little@sei.cmu.edu
cc:       CAD@BRL.MIL
Subject:  Re:  Re: sparc2 port
Message-ID:  &lt;9112202018.aa02518@WOLF.BRL.MIL&gt;

<p>
Considering the number of user sites that we have, and that we don't
have any staff allocated for external user support, it can be a bit
annoying  when people don't experiment a bit with configuration before
calling for help.  We have tried to make configuration choices as
clear and simple as possible.

<p>
Anyway, for some reason it was not clear to me that you wanted an X-only
configuration.  Simply change the lines to remove the if_sun, -DIF_SUN,
dm-sun, -DDM_SUNPW entries, and remove the suntools library references.

<p>
I have expanded our copy of Cakefile.defs to make an X11-only version
an easily configured option.  I did it for Sun-4 machines, the same
idea can be applied to other platforms:

<p>
#if defined(sparc)
/*	Sun-4 "SparcStation" hardware */
#	undef	sun
#	undef	sun4
#	define	MTYPE	sun4
#	define	BSD	43
#	define	HAS_TCP	1
#	if 0
#		define	OPTIMIZER	-O2
#	else
#		define	OPTIMIZER	-g
#	endif
/*#	define	CC_DEFS	-DAUTOSPEC	/* What does this do? */
#	define	LIBMALLOC	/* use vendor library */
#	define	LIBRT_TIMER	timer42
#	if 1
/*		Bare Sun configuration */
#		define	LIBFB_OBJS	if_remote if_sun
#		define	LIBFB_CONFIG	-DIF_REMOTE -DIF_SUN
#		define	LIBFB_LIBES	LIBPKG -lsuntool -lsunwindow -lpixrect
#		define	LIBRT_TIMER	timer42
#		define	MGED_OBJS	dm-sun
#		define	MGED_CONFIG	-DDM_SUNPW
#		define	MGED_LIBES	-lsuntool -lsunwindow -lpixrect
#	else
#		if 1
/*			Sun with X11 (aka "openwin") & Suntools.  Default for SunOS 4.1.1 */
#			define	LIBFB_OBJS	if_remote if_ab if_sun if_X
#			define	LIBFB_CONFIG	-DIF_REMOTE -DIF_AB -DIF_SUN \
				-I/usr/openwin/include -DIF_X
#			define	LIBFB_LIBES	LIBPKG -lsuntool -lsunwindow -lpixrect \
				-L/usr/openwin/lib -lX11
#			if 1
/*				Sun with X11 only */
#				define	MGED_OBJS	dm-sun dm-X
#				define	MGED_CONFIG	-DDM_SUNPW -DDM_X -I/usr/openwin/include
#				define	MGED_LIBES	-lsuntool -lsunwindow -lpixrect \
					-L/usr/openwin/lib -lX11
#			else
/*				Sun with X11 and XGL (an unbundled product) */
/*				Note that at MSIC, -lgks may also be needed */
#				define	MGED_OBJS	dm-xgl dm-X
#				define	MGED_CONFIG	-DDM_XGL -DDM_X -I/usr/openwin/include
#				define	MGED_LIBES	-lxgl -L/usr/openwin/lib -lX11
#			endif
#		else
/*			Sun with X11 ("openwin") ONLY. No Suntools support. */
#			define	LIBFB_OBJS	if_remote if_ab if_X
#			define	LIBFB_CONFIG	-DIF_REMOTE -DIF_AB \
				-I/usr/openwin/include -DIF_X
#			define	LIBFB_LIBES	LIBPKG \
				-L/usr/openwin/lib -lX11
#			define	MGED_OBJS	dm-X
#			define	MGED_CONFIG	-DDM_X -I/usr/openwin/include
#			define	MGED_LIBES	-L/usr/openwin/lib -lX11
#			endif
#		endif
#	endif
#	if 0
/*		"Unbundled" (i.e. "improved") compilers.  Use if you have them */
#		define	CC	/usr/lang/cc
#		define	FC	/usr/lang/f77
#	endif
#endif

<p>
I hope this helps.
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa28325; 3 Feb 92 16:32 EST
Date:     Mon, 3 Feb 92 16:25:45 EST
From:     dome@BRL.MIL
Subject:  What solid am i hitting?
To:       mike@BRL.MIL
To:
Message-ID:  &lt;9202031625.aa16268@VMB.BRL.MIL&gt;

<p>
Mike, how have you been? I've gotten a survey and some info from the Surviac people and returned the questionaire. I talked to Keith Bowman about rt'ing a .g file and he wasn't able to answer my question. I am trying to find the exact solid that i hit when I rt a file, I'd also like to be able to find some of the data for the solid.
thanks - John.

<p>

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa07598; 4 Feb 92 13:46 EST
Date:     Tue, 4 Feb 92 13:43:40 EST
From:     Carla Moyer &lt;carla@BRL.MIL&gt;
To:       Keith@BRL.MIL
cc:       cad-dist@BRL.MIL, mike@BRL.MIL
Subject:  Technical inquiry for BRL-CAD
Message-ID:  &lt;9202041343.aa03137@VMB.BRL.MIL&gt;

<p>
Dear Keith:

<p>
John Ecker &lt;eckerjal@aplcomm.jhuapl.edu&gt;, from the Johns Hopkins Applied
Physics Laboratory, wanted to know how well supported the Apollo DN10000
is supported by BRL-CAD.  He knows there is a configuration set up
in the "cakefiles" but would like some more information.  Keith (Bowman)
is not familiar with the hardware, so he suggested to me that I forward
this on to you.  John's telephone number is (410) 792-6000 ext. 7902.

<p>
Thanks,

<p>
Carla

<p>
<hr>
<hr>
Date:     Wed, 5 Feb 92 0:44:38 EST
From:     Mike Muuss  &lt;mike@brl&gt;
To:       Carla Moyer &lt;carla@brl.mil&gt;
cc:       Keith@BRL.MIL, cad-dist@BRL.MIL, mike@BRL.MIL
Subject:  Re:  Technical inquiry for BRL-CAD
Message-ID:  &lt;9202050044.aa12824@WOLF.BRL.MIL&gt;

<p>
The Apollo DN1000 is not on the "supported" list, but it works OK
last I checked (which was 2 years ago).  I expect that it will take
minor polishing, but can probably be made to work.  If the machine
is on the net, and problems are encountered, I might be able to help
for an hour sometime.  But if Apollo has changed things drasticly,
no telling.

<p>
Also worthy of note is that there is no "local" support for image output
on the DN1000;  only the X-windows interface is available.  And that isn't
the best way to use our software, but it does work.
	Best,
	 -Mike
<hr>
<hr>
Date:     Wed, 5 Feb 92 0:26:55 EST
From:     Mike Muuss  &lt;mike@brl&gt;
To:       dome@BRL.MIL
cc:       Mike@BRL
Subject:  Re:  What solid am i hitting?
Message-ID:  &lt;9202050026.aa12756@WOLF.BRL.MIL&gt;

<p>
Hi John -

<p>
When your a_hit() routine gets called, you have a doubly linked list
of partition structures.  Each partition represents a chunk of solid.
From the partition structure, the element pt_regionp gives you a pointer
to the region structure, which will give you your material properties
info, and the partition name (pt_regionp-&gt;reg_namep).  The elements
pt_inseg and pt_outseg will give you pointers to the segment of the
solid that the in and out points actually struck;  from there, the
primitive solid's name (as opposed to the region name) is found from
pt_inseg-&gt;seg_stp-&gt;st_dp-&gt;d_namep, the entry solid type is in
pt_inseg-&gt;seg_stp-&gt;st_id, and the particular surface number
(specific to each st_id value) is in pt_inseg-&gt;seg_in-&gt;hit_surfno.

<p>
Does this give you enough to go on?  If not, perhaps you can give me
some kind of idea what info you need.
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa15429; 10 Feb 92 10:34 EST
Date:     Mon, 10 Feb 92 10:30:48 EST
From:     Mike Markowski &lt;mmark@BRL.MIL&gt;
To:       phd@BRL.MIL, jill@BRL.MIL, acst@BRL.MIL, davisson@BRL.MIL,
          wm@BRL.MIL
Subject:  brl-cad erim solids
Message-ID:  &lt;9202101030.aa16973@VMB.BRL.MIL&gt;

<p>
While Mike's duties temporarily took him away from our mged solid edit
restructuring, I decided to add another solid, the elliptical torus, to
brl-cad.  Like the others, the only portion untested is surface curvature.

<p>
The full list of new solids is now:

<p>
	RPC, Right Parabolic  Cylinder
	RHC, Right Hyperbolic Cylinder
	EPA, Elliptical Paraboloid
	EHY, Elliptical Hyperboloid
	ETO, Elliptical Torus

<p>
Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa24590; 11 Feb 92 8:41 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa27387; 11 Feb 92 8:14 EST
Date:     Tue, 11 Feb 92 8:08:13 EST
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
To:       Susan Coates &lt;scoates@BRL.MIL&gt;
cc:       cad@BRL.MIL, scoates@BRL.MIL
Subject:  Re:  concat command in mged 4.0
Message-ID:  &lt;9202110808.aa27144@VMB.BRL.MIL&gt;

<p>
Sue,

<p>
	Thank you for pointing out the problem with the MGED "concat" command
under 4.0 of BRLCAD.  I've fixed this locally.  For everyone else, the context
diff below should fix the problem.  Apply to cad/mged/concat.c:

<p>
24a25
&gt; #include &lt;stdio.h&gt;
27d27
&lt; #include &lt;stdio.h&gt;
182c182
&lt;               (void)strncpy( local+ncharadd, name, NAMESIZE-ncharadd );
---
&gt;               (void)strncpy( local+ncharadd, name, NAMESIZE-1-ncharadd );
186c186
&lt;       local[NAMESIZE] = '\0';
---
&gt;       local[NAMESIZE-1] = '\0';
198c198
&lt;               local[NAMESIZE] = '\0';         /* ensure null termination */
---
&gt;               local[NAMESIZE-1] = '\0';       /* ensure null termination */
230a231,234
&gt;               if ((ncharadd + strlen(name)) &gt;= NAMESIZE)
&gt;               	printf("WARNING: solid name \"%s%s\" truncated to \"%s\"\n",
&gt;                               prestr,name, local);
&gt;

<p>
Lee A. Butler
Ballistic Research Laboratory		Internet: butler@brl.mil
Aberdeen P.G., MD 21005-5066		Phone: (410) 278-9200

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa20615; 24 Feb 92 22:18 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id ab15888; 24 Feb 92 17:35 EST
Received: from vgr.brl.mil by VMB.BRL.MIL id aa15701; 24 Feb 92 17:17 EST
Received: from [192.101.175.25] by VGR.BRL.MIL id aa01988; 24 Feb 92 14:52 EST
Received: by max.mrj.com (911016.SGI/911001.SGI)
	for cad@brl.mil id AA03044; Mon, 24 Feb 92 14:54:40 -0800
Date: Mon, 24 Feb 92 14:54:40 -0800
From: John Ko &lt;ko@max.mrj.com&gt;
Message-Id: &lt;9202242254.AA03044@max.mrj.com&gt;
To: cad@BRL.MIL
Subject: RPP on objects

<p>
I have noticed that in rtip-&gt;mdl_min and rtip-&gt;mdl_min is stored the bouding
rectangular parallel piped for a model.  But it seems that the values stored
in the above points are not reflective of any combinatorial regions.

<p>
For example when a cube of 10x10x10 is cut in half by 5x10x10 object,
rtip-&gt;mdl_min and rtip-&gt;mdl_max still give me 10x10x10.

<p>
Am I using them incorrectly or does anyone know of a (painless) simply
way of getting at the bouding RPP for model made up of many combinations.

<p>
Thanks fo any help.

<p>
john ko
mrj, inc
ko@max.mrj.com

<p>

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa23909; 25 Feb 92 1:10 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id ab01234; 25 Feb 92 0:33 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa01228; 25 Feb 92 0:20 EST
Date:     Tue, 25 Feb 92 0:17:27 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       John Ko &lt;ko@max.mrj.com&gt;
cc:       cad@BRL.MIL
Subject:  Re:  RPP on objects
Message-ID:  &lt;9202250017.aa23148@WOLF.BRL.MIL&gt;

<p>
The values mdl_min and mdl_max are the corners of the bounding RPP for
the model.  The bound is computed at "prep" time, and is made as
tight as it can be, without extensive effort.

<p>
In essence, the model RPP is the convex hull of all the solids
in the model which are mentioned at least once in either a
non subtracted or non intersected sense.

<p>
Thus, if you had a small object with a huge object subtracted out, the
model RPP would be that of the small object.

<p>
In your example, of a larger object having a smaller object subtracted
out, the model RPP remains that of the larger (non-subtracted) object.
(The same thing holds true if you are using intersection to discard
unwanted material).

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa05050; 25 Feb 92 11:06 EST
Date:     Tue, 25 Feb 92 10:59:32 EST
From:     "Edwin O. Davisson" (VLD/VMB) &lt;davisson@BRL.MIL&gt;
To:       Mike Muuss &lt;mike@BRL.MIL&gt;
cc:       cad@BRL.MIL
Subject:  Re:  RPP on objects
Message-ID:  &lt;9202251059.aa06215@VMB.BRL.MIL&gt;

<p>
Mike,

<p>
	Suppose I have n solids, { S1, S2, .., Sn } with bounding
RPP's for each Si, RPP(Si),  characterized by the two vectors,

<p>
	[ minXSi, minYSi, minZSi ]   &   [ maxXSi, maxYSi, maxZSi ],

<p>
and I combine the Si's with boolean operations OPi, i.e.

<p>
	region =  OP1 S1 OP2 S2 .. OPn Sn  ( where OPi is "+","u", or "-").

<p>
I want to define an RPP, RPP(k), characterized by

<p>
	[ minXRk, minYRk, minZRk ]   &   [ maxXRk, maxYRk, maxZRk ],

<p>
for the object resulting from the first k combinations in the region
list in terms of RPP(k-1), the bounding box of Sk, and the operation
OPk.

<p>
Starting with the first solid and operation ( I assume it is not "-"),
define

<p>
	RPP(1) = RPP(S1)
i.e.
	[ minXR1, minYR1, minZR1 ] = [ minXS1, minYS1, minZS1 ]
and
	[ maxXR1, maxYR1, maxZR1 ] = [ maxXS1, maxYS1, maxZS1 ]

<p>
For RPP(k), k&gt;1 the definition depends on the specific operation OPk:

<p>
	if OPk = "u" then

<p>
		minXRk =  min ( minXRk-1, minXSk )
		minYRk =  min ( minYRk-1, minYSk )
		minZRk =  min ( minZRk-1, minZSk )

<p>
		maxXRk =  max ( maxXRk-1, maxXSk )
		maxYRk =  max ( maxYRk-1, maxYSk )
		maxZRk =  max ( maxZRk-1, maxZSk )

<p>
	if OPk = "+" then

<p>
		minXRk =  max ( minXRk-1, minXSk )
		minYRk =  max ( minYRk-1, minYSk )
		minZRk =  max ( minZRk-1, minZSk )

<p>
		maxXRk =  min ( maxXRk-1, maxXSk )
		maxYRk =  min ( maxYRk-1, maxYSk )
		maxZRk =  min ( maxZRk-1, maxZSk )

<p>
	if OPk = "-" then

<p>
		minXRk =  minXRk-1
		minYRk =  minYRk-1
		minZRk =  minZRk-1

<p>
		maxXRk =  maxXRk-1
		maxYRk =  maxYRk-1
		maxZRk =  maxZRk-1

<p>

<p>

<p>
Thus, for a union operation, the bounding RPP becomes the smallest
(axis-aligned) RPP that contains the previously defined RPP and the
RPP of the current solid.  This is not the convex hull of these RPP's,
but it is the smallest RPP that contains the convex hull of these
RPP's. ( A convex hull of two sets is the smallest convex set that
contains the two given sets.)

<p>
For the intersection operation it is possible for the RPP's to
get smaller.  In fact, if any of the min components are bigger than
the max components for RPP(k), you have a null region.

<p>
For the subtraction operation, you have just ignored the the RPP of the
subtracted solid.

<p>
	Is this the way the RPP's for REGIONS are defined in terms
of the RPPs of the SOLIDS and the corresponding operations in BRLCAD?
Your last parenthetical comment leads me to believe that your intersection
algorithm does not reduce the region RPP when it sometimes could.

<p>
					Ed
<hr>
<hr>
Date:     Tue, 25 Feb 92 15:20:49 EST
From:     Mike Muuss  &lt;mike@brl&gt;
To:       Jill@BRL.MIL, PHD@BRL.MIL, ACST@BRL.MIL, Davisson@BRL.MIL
cc:       SCoates@BRL.MIL, Ennis@BRL.MIL, Wm@BRL.MIL
Subject:  Re: ICMG meeting in Tucson, trip report
Message-ID:  &lt;9202251520.aa06485@WOLF.BRL.MIL&gt;

<p>
&gt; 	Bill Mermagen discussed the current status of the intermediate
&gt; rayhistory file generator for SRIM that uses RT for raytracing
&gt; functions.  The generator uses a FORTRAN call to write the properly
&gt; formatted FITS header and ray information to a file that can be read by
&gt; SRIM 4.0.  This then makes it possible for a user to use RT and still
&gt; run SRIM 4.0, a relatively painless transition from the current
&gt; approach.  Users of SRIM have been given the option of tagging specific
&gt; solid faces with certain material properties; this can lead to ambiguous
&gt; material definition.  Mermagen's approach has only allowed the user
&gt; access to the region identifiers--if a certain surface needs a
&gt; particular material type, the geometry must be explicitly modeled.
&gt; Mike Muuss indicated at some point that surface identifiers could be
&gt; provided with some small work, but that hasn't happened. ...

<p>
In BRL-CAD Release 4.0, I call your attention to

<p>
struct hit {
	:
	:
	int		hit_surfno;	/* solid-specific surface indicator */
};

<p>
which is provided at every point a ray enters and exits a region.

<p>
If you have some way of making sense of the different surfaces of
the different solids that go into making up a region, you are welcome to
use the information.  It has always been present for purposes internal
to the library;  in Release 4.0 I gave the variable a more descriptive
name, knowing that the ERIM folks had need of it.  There isn't any
documentation on how to use it, other than the source code of the
geometry modules, but the legal values are all clearly #defined.
A header file could be created if they are going to start getting used
by applications.

<p>
I would be interested in learning more about what use these numbers would
be put to.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa06623; 25 Feb 92 15:29 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa10261; 25 Feb 92 15:08 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa10070; 25 Feb 92 14:52 EST
Date:     Tue, 25 Feb 92 14:51:37 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       "John R. Anderson" &lt;jra@BRL.MIL&gt;
cc:       cad@BRL.MIL
Subject:  Re:  [Mike Muuss: Re: RPP on objects]
Message-ID:  &lt;9202251451.aa06309@WOLF.BRL.MIL&gt;

<p>
John Anderson writes:

<p>
&gt; 	Along the same lines, Mike, are the bounding boxes for each
&gt; individual object in the model available somewhere. We have occasion
&gt; to need this info and it would be convenient to have a little code to
&gt; spew them out.

<p>
The answer is yes, if you don't mind calling a subroutine.

<p>
If you have a ray partition (struct partition), pp-&gt;pt_regionp gives you
a pointer to the (struct region) that you hit.  So, declare a region pointer,
and the min and max points of your RPP:

<p>
	struct region	*regp = pp-&gt;pt_regionp;
	point_t		rpp_min, rpp_max;

<p>
	rt_bound_tree( regp-&gt;reg_treetop, rpp_min, rpp_max );

<p>
Now you have the RPP of that region in rpp_min and rpp_max.  Note that if

<p>
	if( region_max[X] &gt;= INFINITY )

<p>
then this region is infinite, e.g., it has a non-subtracted halfspace in
it, and the RPP has no meaning -- it's infinite too.  (For computation
purposes, a specific number has been chosen to represent infinity, so
that it can be tested against.  The exact value is machine specific, but
is always at least 1.0e+20 mm, which satisfies all but the astronomers
in the crowd.

<p>
A similar procedure can be used to find the bounding RPP of an
individual solid, but I'd be surprised if you really wanted that.

<p>
Hope this helps!
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa06723; 25 Feb 92 15:31 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id ab10515; 25 Feb 92 15:21 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa10418; 25 Feb 92 15:13 EST
Date:     Tue, 25 Feb 92 15:08:13 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       "Edwin O. Davisson" &lt;davisson@BRL.MIL&gt;
cc:       CAD@BRL.MIL
Subject:  Re:  RPP on objects
Message-ID:  &lt;9202251508.aa06438@WOLF.BRL.MIL&gt;

<p>
Thanks for the nice note, Ed.  In fact, I mis-"spoke" when I said
"convex hull";  the bound is tighter than that, and the algorithm used
is precisely the one you spelled out.  You described it to me some years
ago, and the new tree walker implements it.

<p>
But this observation does not help the fellow I was responding to,
because, as you noted:

<p>
&gt; For the subtraction operation, you have just ignored the the RPP of the
&gt; subtracted solid.

<p>
whereas he was expecting the RPP to shrink after a subtraction.  While I
would enjoy having a tighter bound in that case, I don't know any cheap
way it could be calculated.  About the best I could suggest would be to
tessellate, evaluate the boolean using the NMG code, and find the
bounding RPP of that.  Not exactly cheap. And I wouldn't suggest
depending on the BRL-CAD 4.0 release to do any hard booleans.

<p>
I'm sure that folks will be happy to know that after a nearly year-long
haiatus, NMGs are again getting active attention.  Forward progress (as
opposed to congress) is being made.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa07946; 25 Feb 92 17:08 EST
Date:     Tue, 25 Feb 92 16:57:42 EST
From:     "Edwin O. Davisson" (VLD/VMB) &lt;davisson@BRL.MIL&gt;
To:       Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  My previous note
Message-ID:  &lt;9202251657.aa11171@VMB.BRL.MIL&gt;

<p>

<p>
Mike,

<p>
	Perhaps it is the downfall of a mathematician to be
perpetually nitpicky but,

<p>

<p>
&gt;Thanks for the nice note, Ed.  In fact, I mis-"spoke" when I said
&gt;"convex hull";  the bound is tighter than that..
&gt;                             ^^^^^^
&gt;                              no.

<p>

<p>
Example:

<p>
	u S1 u S2

<p>
	with S1 and S2 as RPP's and so they are their own bounding
	RPP's:

<p>

<p>

<p>

<p>

<p>
		|---------------|
                |               |
                |               |
                |               |
                |               |
                |               |
                |     |---------|-----|
                |     |         |     |
                |     |         |     |
                |     |         |     |
                |-----|---------|     |
                      |               |
                      |               |
                      |               |
                      |               |
                      |---------------|

<p>
but the convex hull of the RPP's ( here both the solids and the bounding RPPs
look like this:

<p>
		|----------------\
                |                 \
                |                  \
                |                   \
                |                    \
                |                     \
                |                     |
                |                     |
                |                     |
                |                     |
                \                     |
                 \                    |
                  \                   |
                   \                  |
                    \                 |
                     \----------------|

<p>

<p>
whereas the resulting RPP would be this:

<p>

<p>
		|---------------------|
                |                     |
                |                     |
                |                     |
                |                     |
                |                     |
                |                     |
                |                     |
                |                     |
                |                     |
                |                     |
                |                     |
                |                     |
                |---------------------|

<p>
which is less restrictive than the convex hull would be.

<p>

<p>

<p>
One other thing: you didn't address the question of whether the current
method reduces the bounding RPP when intersections take place.  Your
first note implied in the last sentence that the intersection would
simply ignore the second RPP upon intersection.  The method I described
reduces the RPP in such a case:

<p>
if in the case above we had S1+S2, then the bounding RPP would
be the little box:

<p>

<p>
		|---------------|
                |               |
                |               |
                |               |
                |               |

<p>

<p>
                |     |---------|  ---|
                |     |         |     |
                |     |         |     |
                |     |         |     |
                |--   |---------|     |

<p>

<p>
                      |               |
                      |               |
                      |---------------|

<p>

<p>

<p>
						Ed
<hr>
<hr>
Received: from vim.brl.mil by WOLF.BRL.MIL id aa27133; 28 Feb 92 11:23 EST
Received: from VIM.BRL.MIL by VIM.BRL.MIL id aa15020; 28 Feb 92 11:15 EST
Received: from vmb.brl.mil by VIM.BRL.MIL id aa14633; 28 Feb 92 11:07 EST
Date:     Fri, 28 Feb 92 10:41:56 EST
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.MIL&gt;
To:       vld@BRL.MIL
Subject:  Lgt bug fixes available.
Message-ID:  &lt;9202281041.aa00757@VMB.BRL.MIL&gt;

<p>
Lgt users,

<p>
	I have improved the hidden-line algorithm so that highly oblique
surfaces no long get erroneously filled in.  Thanks to Tyler Brown and
Keith Applin for showing me a particularly pathological example of this
problem; I was aware of it as a design flaw, but didn't have a solution
for it.  The severity of the example inspired me to revisit the problem.
The fix involves testing for high obliquity against a built-in tolerance
so if anyone still sees black areas I may need to tweak the tolerance a
bit or make it user selectable.  Note that low resolution will typically
result in filled in areas (thick lines) where adjacent edges merge, but a
1024x1024 resolution can typically resolve the edges better, this is not
a fault in the algorithm.  Use of the anti-alias lgt option can further
improve the apparent resolution with hidden-line drawings, it's not just
for color shaded images.  I am not aware of any remaining shortcomings in
the hidden-line algorithm, let me know if you see any missing or spurious
edges in your lgt images in the future.

<p>
	There was also a minor bug where lgt would claim that a certain
number of processors were in use when the user had in fact configured
in a different number.  This was due to printing the message after all
UNIX shell command-line options were processed, but before all user
commands were read from the standard input.  This was easily fixed,
thanks to Sue Coates for reporting this bug.

<p>
	I have installed the fixed lgt yesterday on walrus in the BRL-CAD
distribution, so all of the SGIs that get the rdist should receive it by
today or tomorrow.  The older version is still available as lgt.bak.

<p>
-Gary

<p>
<hr>
<hr>
Date:     Tue, 1 Oct 91 2:59:57 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
To:       ACST@BRL.MIL
Subject:  SGI CAD performance boost
Message-ID:  &lt;9110010259.aa21770@WOLF.BRL.MIL&gt;

<p>
This evening, I made some modifications to librt, so that
per-cpu statistics are now kept secretly in struct resource,
and then merged into the rt_i struct after parallel processing ends.

<p>
This has resulted in the SGI results for 8 processors going from
4X one processor, up to 6X.

<p>
A pretty good fix, but I think some more performance can still be found.

<p>
My tentative conclusion is that multi-processor interlocks may have
gotten somewhat more expensive in IRIX 4.0, but I don't have any
firm indictment.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa23114; 17 Mar 92 1:45 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa21455; 17 Mar 92 1:14 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa21404; 17 Mar 92 0:58 EST
Date:     Tue, 17 Mar 92 0:57:40 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  errata4.0-irix4
Message-ID:  &lt;9203170057.aa22896@WOLF.BRL.MIL&gt;

<p>
Just now, I have placed the file "brl-cad/errata4.0-irix4" on
ftp.brl.mil for anonymous FTP, containing a script which will upgrade
your BRL-CAD Release 4.0 distribution for use on an SGI running IRIX
4.0.1.

<p>
-r--r--r--   1 mike     graphics  256381 Mar 17 00:54 errata4.0-irix4

<p>
Here is the head of that file:

<p>
          ++++++++++++++++++++          ++++++++++++++++++++

<p>
As promised, this file contains a comprehensive set changes to the
BRL-CAD Release 4.0 which are necessary to compile the software on
Silicon Graphics (SGI) workstation with the latest operating system
releases, IRIX 4.0.0, and IRIX 4.0.1. In general, these changes should
also be applied on other kinds of systems as well.

<p>
This file *includes* all the modifications from these four existing errata
sheets:

<p>
-r--r--r--   1 mike     graphics    4245 Mar 16 20:58 errata4.0-cake
-r--r--r--   1 butler   graphics     444 Nov 15 12:23 errata4.0-fbserv
-r--r--r--   1 butler   graphics     349 Nov 15 12:23 errata4.0-pixscale
-r--r--r--   1 mike     graphics    1054 Nov  2 03:13 errata4.0-sun-xgl

<p>
This means that you only have to run this one script before starting to
compile everything.

<p>
Note that on IRIX 4.0.1, programs which link with LIBRT will produce the
following two warning messages, which are due to a harmless (but
annoying) SGI library bug.  They can be safely ignored:

<p>
/usr/bin/ld:
Warning: _oserror: multiply defined
        previous (used) definition from '/usr/lib/libmpc.a';
        new (ignored) definition from '/usr/lib/libc_s.a'
Warning: _setoserror: multiply defined
        previous (used) definition from '/usr/lib/libmpc.a';
        new (ignored) definition from '/usr/lib/libc_s.a'

<p>
Cut off this top part of the file, and run the rest as a shell script.
Note that it must be run from the top directory of your CAD source tree.
"cd cad" before running it.

<p>
	Best,
	 -Mike Muuss

<p>
          ++++++++++++++++++++          ++++++++++++++++++++
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa29587; 17 Mar 92 17:33 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa29714; 17 Mar 92 17:23 EST
Received: from vgr.brl.mil by VMB.BRL.MIL id aa29599; 17 Mar 92 17:15 EST
Received: from uv4.Eglin.AF.MIL by VGR.BRL.MIL id aa15438; 17 Mar 92 16:34 EST
Date: 17 Mar 92 15:20:00 CST
From: BRUENNIN@uv4.eglin.af.mil
Subject: errata4.0-irix4 install report
To: CAD &lt;CAD@BRL.MIL&gt;
Message-ID:  &lt;9203171635.aa15438@VGR.BRL.MIL&gt;

<p>
                               E G L I N     A F B

<p>
From:  LEONARD E. BRUENNING                 Date:     17-Mar-1992 02:47pm CST
       BRUENNIN                             Tel No:   904 729 6226
Dept:  ASD/YBES*SVERDRUP

<p>
TO:    Internet Addressee                   ( _SMTP[CAD@BRL.MIL] )

<p>
CC:    ROBERT L. STOVALL                    ( STOVALL )
CC:    ELIZABETH T. THORN                   ( THORN )
CC:    MILFORD A. REYNOLDS                  ( REYNOLDS )
CC:    JOHN A. COLLINS                      ( COLLINS )

<p>
Subject: errata4.0-irix4 install report

<p>
Received and installed errata4.0-irix4 today on an SGI-4D/35.  (Used to be a
4D20 but was upgraded) running IRIX 4.0.1.  Everything went pretty smooth and "-
most" stuff seems to be ok.  However, a few difficulties were encountered:

<p>
1)  'edpix' utility was not compiled or installed.  I think this is because of
the code in gen.sh that skips the edpix code if the machine is NOT defined as a
4D.  Strangely enough, this machine now responds to machinetype.sh as a 5D which
apparently causes the edpix code to be skipped.

<p>
2)  rpatch and patch-g executables not compiled or installed.  This seems to be
because the 'patch' directory is listed in the CDIRS list in gen.sh which,
according to the comments, is for codes without cakefiles which really isn't the
case for the rpatch and patch-g programs.

<p>
3)  This machine has a 360MB internal hard drive holding the / and /usr file
systems and an external 1.2GB drive holding the /usr2 file system.  With the
advent of IRIX4.0.1, there was not enough room on the /usr file system for the
brlcad executables.  Therefore, I elected the option indicated in the
install.tr file and redefined by BINDIR, LIBDIR, and ETCDIR definitions in the
appropriate files.  This seemed to work fine EXCEPT for the man pages.  The
'brlman' command was found - would respond with a usage prompt if no args were
given - but would respond with nothing if any arg was provided.  Turned out,
definitions in the brlman and awf scripts in the ./bin directory ALSO had to be
changed to reflect my non-standard installation.

<p>
4)  I have executed most of the utilities I normally used and all seem OK EXCEPT
rle-fb.  This sits there apparently awaiting additional input.  It seems that a
file pointer (*infp at line 33 in rle-fb.c) had to be changed so it would
compile but the change to 'stdin' seems to cause some problems here.  I would
appreciate some assistance in this area.

<p>
Hope this report is useful.

<p>
Bud Bruenning, Sverdrup/TEAS Group, (904) 729-6226

<p>

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa11852; 17 Mar 92 23:59 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa03996; 17 Mar 92 23:34 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa03994; 17 Mar 92 23:31 EST
Date:     Tue, 17 Mar 92 23:23:58 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       BRUENNIN@uv4.eglin.af.mil
cc:       CAD &lt;CAD@BRL.MIL&gt;
Subject:  Re:  errata4.0-irix4 install report
Message-ID:  &lt;9203172323.aa11656@WOLF.BRL.MIL&gt;

<p>
Bud -

<p>
Thanks for the detailed report, it was most helpful!

<p>
At BRL we are running both IRIX 3 and IRIX 4 systems.  They are
sufficiently different, that we needed "machinetype.sh" to distinguish
between them. Since IRIX 3 systems are called "4d", IRIX 4 systems got
named "5d".

<p>
1)  re: edpix.  You are correct, gen.sh has a special case for EDPIX
that only works on "4d", but not "5d".  Fixed, below.

<p>
2)  re:  patch directory.  Correct again.  Now that the patch tools
have a Cakefile, they need to move from the CDIRS to BDIRS list.  Fixed,
below

<p>
3)  re:  /usr overflow.  In a case such as yours, I would recommend
using a symbolic link, rather than changing the definitions, although
it *is* useful to know what got overlooked....  More specifically,
what I'd do is something like this:

<p>
	mkdir /usr2/brlcad
	ln -s /usr2/brlcad /usr/brlcad
	cd /usr/brlcad
	mkdir bin lib etc man .....

<p>
The symbolic link will not present a performance problem.  However, I'll
look into what got overlooked.  (I note that newbindir.sh has the
brlman/awf and brlman/brlman entries, even though install.tr does not.
I have updated the development copy to reflect this change).

<p>
If you hadn't updated the setting of $MANPATH in your environment,
that might have been the problem with the "brlman" command, especially
if you also had not changed the MANPATH=/usr/brlcad/man line in
brlman/brlman.

<p>
4)  re:  rle-fb.  I blew it, the fix was wrong.  Fixed, below.

<p>
&gt; Hope this report is useful.
&gt; Bud Bruenning, Sverdrup/TEAS Group, (904) 729-6226

<p>
The report was very useful.  In response to it, I have created a new
version of the errata sheet which addresses items 1, 2, and 4, above.
I have installed this updated version into FTP.BRL.MIL's brl-cad
directory in place of yesterday's version.  When this new version is
applied, the CAD software will identify itself as BRL-CAD Release 4.1,
to distinguish it from the unpatched software.

<p>
Here is the heading of the new, second edition, patch file:

<p>
          ++++++++++++++++++++          ++++++++++++++++++++

<p>
This document is at $Revision$.

<p>
As promised, this file contains a comprehensive set changes to the
BRL-CAD Release 4.0 which are necessary to compile the software on
Silicon Graphics (SGI) workstation with the latest operating system
releases, IRIX 4.0.0, and IRIX 4.0.1. In general, these changes should
also be applied on other kinds of systems as well.

<p>
Applying this patch file will bring your software up to BRL-CAD Release 4.1.

<p>
This file *includes* all the modifications from these four existing errata
sheets:

<p>
-r--r--r--   1 mike     graphics    4245 Mar 16 20:58 errata4.0-cake
-r--r--r--   1 butler   graphics     444 Nov 15 12:23 errata4.0-fbserv
-r--r--r--   1 butler   graphics     349 Nov 15 12:23 errata4.0-pixscale
-r--r--r--   1 mike     graphics    1054 Nov  2 03:13 errata4.0-sun-xgl
and
-r--r--r--   1 mike     graphics   30388 Nov  9 04:58 cad4.0.tar-patch.Z

<p>
This means that you only have to run this one script before starting to
compile everything.

<p>
Note that on IRIX 4.0.1, programs which link with LIBRT will produce the
following two warning messages, which are due to a harmless (but
annoying) SGI library bug.  They can be safely ignored:

<p>
/usr/bin/ld:
Warning: _oserror: multiply defined
        previous (used) definition from '/usr/lib/libmpc.a';
        new (ignored) definition from '/usr/lib/libc_s.a'
Warning: _setoserror: multiply defined
        previous (used) definition from '/usr/lib/libmpc.a';
        new (ignored) definition from '/usr/lib/libc_s.a'

<p>
Cut off this top part of the file, and run the rest as a shell script.
Note that it must be run from the top directory of your CAD source tree.
"cd cad" before running it.

<p>
	Best,
	 -Mike Muuss

<p>
          ++++++++++++++++++++          ++++++++++++++++++++
<hr>
<hr>
Date:     Fri, 20 Mar 92 12:05:00 EST
From:     Mike Muuss  &lt;mike@brl&gt;
To:       Paul Tanenbaum &lt;pjt@server.cs.jhu.edu&gt;
cc:       ACST@BRL, Gwyn@BRL, fsbrn@BRL
Subject:  Re:  free(2) Question
Message-ID:  &lt;9203201205.aa08118@WOLF.BRL.MIL&gt;

<p>
&gt; To: fsbrn@BRL.MIL, gwyn@BRL.MIL, mike@BRL.MIL, stay@BRL.MIL
&gt; Subject: free(2) Question
&gt; From: Paul Tanenbaum &lt;pjt@server.cs.jhu.edu&gt;
&gt;
&gt;      Sorry for the unsophisticated approach to the selection of addressees:
&gt; I just thought up a bunch of people, some set of whom would probably know the
&gt; answer to this question  (I've RTFM already, and not found the answer)...
&gt; Is the following hunk of code kosher:
&gt;
&gt; 	foo ()
&gt; 	{
&gt; 	    widget	*wp;	/* data type defined elsewhere */
&gt;
&gt; 	    if ((wp = (widget *) malloc(10 * sizeof(widget))) == NULL)
&gt; 	    {
&gt; 		fputs("foo():  Can't fit 10 widgets\n", stderr);
&gt; 		exit (1);
&gt; 	    }
&gt;
&gt; 	    do_something(wp);
&gt;
&gt; 	    /* Hereafter need only the first 2 widgets */
&gt; 	    free(wp + 2);
&gt; 	}
&gt;
&gt; In other words, is it reasonable to pass free() an address in the middle of
&gt; an allocated block, instead of the address of the start of the block?

<p>
No.  Quoting from the SGI man page, which is most handy:

<p>
     The argument to free is a pointer to a block previously allocated by
     malloc.

<p>
If you didn't get it with malloc(), you shouldn't feed it to free().
The reason for this is that malloc/free use a small data structure just
before the dynamic memory block is.  The contents are system-specific,
but often include things like:

<p>
*)  Forward and backwards links of free/busy memory blocks
*)  The size of the memory block.
*)  The busy/free status of the memory block.
*)  Magic numbers to check for pointer corruption

<p>
&gt; The
&gt; application was calling malloc() to get a starting chunk and then repeatedly
&gt; calling realloc() to double that amount as needed.  Since in the worst case
&gt; this approach will use twice the required memory, I thought I'd give back
&gt; what I didn't need.  I ended up dumping core, however, and inferred that
&gt; malloc()/free() might not be as sophisticated as I had assumed.

<p>
Or more sophisticated!  In this case, what you should be doing is
calling realloc() again to trim down the size of the block to exactly
what is needed.  Then the library will be able to shuffle the remainder
off to it's internal free list, building new headers & other internal
info as appropriate for that implementation.

<p>
Using realloc() to shrink the size of an allocation is not an expensive
operation, and won't move the actual data (although it would be safest
not to depend on that behavior).

<p>
	Best,
	 -Mike

<p>
<hr>
<hr>
Date:     Fri, 20 Mar 92 11:37:01 EST
From:     Mike Muuss  &lt;mike@brl&gt;
To:       joe edward meier &lt;jem@bruker.com&gt;
cc:       Mike Moss &lt;mike@brl.mil&gt;
Subject:  Re:  BRL-CAD drafting features
Message-ID:  &lt;9203201137.aa07010@WOLF.BRL.MIL&gt;

<p>
&gt; ... I have some questions regarding BRL-CAD's ability
&gt; to create production drawings.  The documentation mentioned some work
&gt; being done with automatic dimension, is anything available for
&gt; incorporating into BRL-CAD?  Even a primitive (Beta) version would be
&gt; useful.  Also, is there a command to make BRL-CAD produce the drafting
&gt; drawings, or does one have to use seperate commands?

<p>
What we have, so far, is RTHIDE, RTSCALE, and RTREGIS.

<p>
&gt;   Also, the documentation mentions a numerical milling program, is
&gt; there a version of this avaliabe?  I would be very interested in one.

<p>
Nope, sorry.

<p>
&gt;   I also was wondering what the vector font directory (vfont) was for,
&gt; is there some way to annotate the images, and what is libnurb for,
&gt; does BRL-CAD have a method for produceing nurb solids, or does one
&gt; have to create those outside of BRL-CAD?

<p>
vfont directory is used by CAT-FB, which puts troff output onto framebuffers
and image files, and FBLABEL which is used for annotating images, usually
from shell scripts.

<p>
libnurb is for the analysis of NURB solids.  We don't allow interactive
creation or editing of NURBS yet, but if you have a program that wants
to create a NURB, it's easy!  Look at proc-db/teapot.c for one example.

<p>
&gt;   These questions where some things I came up with while reading the
&gt; documintation and which I would like more information before I go to
&gt; the effort of porting the package to my MAC.  Being in the NMR software
&gt; busness myself I can understand how easy it is to let the documentation
&gt; fall behind.

<p>
Actually, the documentation is in pretty fair shape.  Problem is, our
support contractor that was organizing all the camera-ready copy for
the printshop is now 6 months late in delivering, so all you users don't
actually HAVE the latest documentation. Sigh.  It's a 5 volume set now.

<p>
	Best,
	-Mike
<hr>
<hr>
Received: from vgr.brl.mil by WOLF.BRL.MIL id aa08552; 20 Mar 92 13:36 EST
Date:     Fri, 20 Mar 92 13:12:40 EST
From:     Doug Gwyn (VLD/VMB) &lt;gwyn@BRL.MIL&gt;
To:       Mike Muuss &lt;mike@BRL.MIL&gt;
cc:       Paul Tanenbaum &lt;pjt@server.cs.jhu.edu&gt;, ACST@BRL.MIL, Gwyn@BRL.MIL,
          fsbrn@BRL.MIL
Subject:  Re:  free(2) Question
Message-ID:  &lt;9203201312.aa00830@VGR.BRL.MIL&gt;

<p>
realloc() might or might not move the data and it might fail, even for a
request to shorten the allocation.  Standard-conforming implementations
of realloc() will not lose the original data when they report failure.
(Older implementations sometimes did.)  The programming idiom for this is:
	/* using p to refer to the start of the data block */
	if ( (np = realloc( p, new_size )) != NULL )	/* and only if */
		p = np;
	/* continue to use p to refer to the start of the data block */
(For clarity, I omitted details such as declarations, etc.)

<p>
An easy mistake to make is to store addresses within the previous data
block into various pointer variables (e.g. sparse-array links), then
fail to update them upon realloc()ation (probably because you didn't
leave yourself any way to find them!).  If you key off (base,offset)
instead, then updating just the base pointer to the data block is all
that is necessary to track a realloc()ation (the offsets don't change).
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa18631; 13 Apr 92 15:53 EDT
Date:     Mon, 13 Apr 92 15:53:20 EDT
From:     Carl Moore (VLD/VMB) &lt;cmoore@BRL.MIL&gt;
To:       acst@BRL.MIL
cc:       cmoore@BRL.MIL
Subject:  can't draw solid type 21?
Message-ID:  &lt;9204131553.aa16761@VMB.BRL.MIL&gt;

<p>
On vsb50.brl.dis, using a Silicon Graphics terminal, I ran MGED, which
said BRL-CAD 4.0 (mike@walrus.brl.mil:/sunvld/mike/mged), and if I try
to edit a certain region:

<p>
E regionname

<p>
I get:

<p>
proc_reg:  Cannot draw solid type 21 (ARS)
Error in converting solid regionname to ARBN
E: 0 vectors in 0 sec

<p>
(but little "e" works OK; this region is not all that complicated, and
big E should have worked pretty quickly)
Let me know if you want a closer look at this case.
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa21751; 14 Apr 92 7:39 EDT
Date:     Tue, 14 Apr 92 7:38:29 EDT
From:     Keith Applin (VLD/VMB) &lt;keith@BRL.MIL&gt;
To:       cmoore@BRL.MIL
cc:       acst@BRL.MIL
Subject:  Re: can't draw solid type 21?
Message-ID:  &lt;9204140738.aa02524@VMB.BRL.MIL&gt;

<p>
Carl:

<p>
The "E" command doesn't do ARSs or TORs and never has.

<p>
		-keith-

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa17420; 18 Apr 92 2:27 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00396; 18 Apr 92 2:24 EDT
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa00389; 18 Apr 92 2:18 EDT
Date:     Sat, 18 Apr 92 2:09:36 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  dm-4d performance
Message-ID:  &lt;9204180209.aa17055@WOLF.BRL.MIL&gt;

<p>
This evening, while working on part of our experimental Virtual Reality (VR)
support in MGED, I was able to make an optimization to dm-4d.c, the
display manager for the SGI Iris 4D workstations, which improved graphics
drawing speed by 25% in the test case I tried.

<p>
The model was bldg391.g.  I gave these commands:
	e all.g
	ae 35 25
	size 4000
	knob x 1

<p>
On the Release 4.1 version of the code, I obtained 12.5 frames/sec,
while with the new version, I obtained 15.75 frames/sec.
(I might note that the new MGED also continuously monitors it's drawing
performance now, making it easy to read off frame rates).

<p>
	Onwards!
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa17620; 18 Apr 92 3:09 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00695; 18 Apr 92 3:08 EDT
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa00669; 18 Apr 92 2:59 EDT
Date:     Sat, 18 Apr 92 2:48:14 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  MGED perspective handling
Message-ID:  &lt;9204180248.aa17492@WOLF.BRL.MIL&gt;

<p>
As another part of the VR modifications, the handling of perspective viewing
in MGED has been moved up from dm-4d.c into dozoom.c, so that all display
managers (such as X, PostScript, Tektronix, Unix-Plot, etc) now have
support for perspective drawing, rather than just the SGI.
	Best,
	 -Mike
<hr>
<hr>
Received: from spark.brl.mil by WOLF.BRL.MIL id aa20192; 22 Apr 92 20:41 EDT
Date:     Wed, 22 Apr 92 20:48:09 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       ACST@BRL.MIL
cc:       vis@BRL.MIL
Subject:  BRL-CAD updates
Message-ID:  &lt;9204222048.aa12601@SPARK.BRL.MIL&gt;

<p>
FYI, I installed some updates in the BRL-CAD tree today:

<p>
1) pix-ps
   Fixes problem with unusual file sizes that would cause stripes
     at the top, or failure to print.
   Quite a bit faster (uses builtin hex printer rather than printf)
   Page centering now default (with -l for lower left - which I doubt
   anyone used anyway).

<p>
2) loop
   John Grosh's latest floating point and leading zero version.

<p>
3) c-d
   argv dereference bug (would dump core on SGI's)
   protected atan2 against 0,0 calls.

<p>
- Phil
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa08488; 31 Jan 92 19:12 EST
Received: from vmb.brl.mil by VMB.BRL.MIL id aa23391; 31 Jan 92 19:03 EST
Date:     Fri, 31 Jan 92 18:49:48 EST
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
To:       Paul Tanenbaum &lt;pjt@BRL.MIL&gt;
cc:       cad@BRL.MIL
Subject:  framebuffers under BRLCAD 4.0
Organization:  Doubly-Linked_List
Message-ID:  &lt;9201311849.aa23249@VMB.BRL.MIL&gt;

<p>
Paul,

<p>
	The lack of a shared memory framebuffer on the Indigo is not as
burning an issue as you might at first think.  The reason is that with
release 4.0 BRLCAD has "fbserv".  This is known as the "framebuffer server".
The idea is that you create a process which opens a framebuffer and handles
requests for that framebuffer.  This allows you to create 1 framebuffer window
for working with images, and removes the "popping window" syndrome.  One of
the great misfortunes of release 4.0 is that there is no man page for fbserv,
and the useage message is of limited help.  I will try to give a brief
overview here.

<p>
fbserv opens a framebuffer window and lingers around waiting to service
framebuffer requests.  An application opens this framebuffer and reads/writes
just like normal.  The difference is that when the application closes the
framebuffer the server does not close down the window and go away.  Instead it
goes back to waiting for new framebuffer requests.  The next application to
open framebuffer 0 gets the same fbserv, with the same framebuffer window and
display memory as before.  When the user finally wants to dismiss the
framebuffer entirely (ie: at logout time) the command "fbfree" will caues
fbserv to dismiss the actual framebuffer and then exit.

<p>
This method of operation has several advantages over previous methods of
operation.  The first is that the user gets a framebuffer window that doesn't
"disappear" as soon as the application closes the framebuffer (as is the case
with a framebuffer of "/dev/sgi").  Traditionally the workaround was to use
a "lingering" framebuffer.  The problem with this was that the window had to
be dismissed by the user after each use or there would be a buildup of
"duplicate" windows on the screen.

<p>
In addition to the "user interface" problem, there was the problem of using
"shared memory" to hold the image.  On many (if not all) systems, a shared
memory segment was not pageable/swappable. This meant that a single paint of a
1024x1024 image would lock up 3MBytes of main memory until a user explicitly
freed the shared memory segment.  Few people remember to do this.  On many
workstations, the loss of 3MB poses a severe penalty on system performance.

<p>
Finally, it is possible with fbserv to maintain 2 independent framebuffers on
the same system.  This can be useful for comparing images, or allow rendering
into one framebuffer while other images are viewed into a second.

<p>
Example:

<p>
	% fbserv -S 512 0 /dev/sgip &			# start server #1
	% fbserv -S 512 1 /dev/sgip &			# start server #2
	% setenv FB_FILE 1
 	% pix-fb -F 0 image.pix
 	% pix-fb picture.pix
 	% rt -a 35 -e 25 moss.g all.g &gt;& moss.log &
 	[1] 10671
	% setenv FB_FILE 0
 	% fb-rle image.rle
 	% jobs
	[1]  + Running  rt -s 512 -a 35 -e 25 moss.g all.g &gt;& moss.log
 	%
	[1]    Done      rt -s512 -a 35 -e 25 moss.g all.g &gt;& moss.log

<p>

<p>
It is important to note that "fbserv" can use any valid framebuffer name.
Fbserv works equally well on a sun, sgi, cray....

<p>
Lee A. Butler
Ballistic Research Laboratory		Internet: butler@brl.mil
Aberdeen P.G., MD 21005-5066		Phone: (410) 278-9200
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa01219; 14 May 92 16:08 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac22974; 14 May 92 16:00 EDT
Received: from vgr.brl.mil by VMB.BRL.MIL id aa22830; 14 May 92 15:55 EDT
Received: from dragon.dst.battelle.org by VGR.BRL.MIL id aa17394;
          14 May 92 15:42 EDT
Received: by dragon.dst.battelle.org (911016.SGI/911001.SGI)
	for cad@brl.mil id AA04365; Thu, 14 May 92 15:45:14 -0400
Date: Thu, 14 May 92 15:45:14 -0400
From: doug everhart &lt;doug@dragon.dst.battelle.org&gt;
Message-Id: &lt;9205141945.AA04365@dragon.dst.battelle.org&gt;
To: cad@BRL.MIL
Subject: Frame Buffer (fb) Problems

<p>
I've got a problem running the fb routines on my SGI 4D/220.  The window
that the fb opens comes up and plots the image and then disappears as
soon as the image is complete (along with the image).  Any hints as to
how I can fix this?  Thanks.

<p>

<p>
---------------------------------------------------------------------------

<p>
R. Douglas Everhart                           (614)424-3214
Principal Research Scientist              FAX:(614)424-3776
                                          doug@dragon.dst.battelle.org
Battelle Memorial Institute
505 King Ave.
Columbus, Ohio  43201

<p>
---------------------------------------------------------------------------

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa02699; 14 May 92 22:08 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00532; 14 May 92 22:04 EDT
Received: from spark.brl.mil by VMB.BRL.MIL id aa00415; 14 May 92 21:53 EDT
Date:     Thu, 14 May 92 21:46:37 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       doug everhart &lt;doug@dragon.dst.battelle.org&gt;
cc:       cad@BRL.MIL
Subject:  Re:  Frame Buffer (fb) Problems
Message-ID:  &lt;9205142146.aa08791@SPARK.BRL.MIL&gt;

<p>
Try "setenv FB_FILE /dev/sgipl" and then pix-fb.  The 'p' option means
private memory (not shared) and the 'l' means to linger, i.e. stay around
after the program that created the window has exited.  See "fbhelp"
for more information.

<p>
Another option is fbserv, which creates a reusable window.  E.g.

<p>
% fbserv -w720 -n486 0 /dev/sgip &
% setenv FB_FILE 0
% pix-fb -s512 file.pix
% fbzoom

<p>
etc.

<p>
You can have several fbserv's known as '0', '1', etc.  They work
remotely as well:

<p>
remotehost% setenv FB_FILE yourfbservhost:0
remotehost% pix-fb

<p>
[Not to be confused with the X11 setenv DISPLAY hostname:0, but the
 syntax is very similar.  If you are using the /dev/X frame buffer,
 you still need to set DISPLAY, xhost, etc.]

<p>
- Phil
<hr>
<hr>
Date:     Fri, 15 May 92 6:52:03 EDT
From:     Jim Hunt  &lt;jehunt@brl&gt;
To:       vld-lttb@BRL.MIL
cc:       mike@BRL.MIL, moss@BRL
Subject:  Region ID Instance Filter installed in RIP
Message-ID:  &lt;9205150652.aa04620@WOLF.BRL.MIL&gt;

<p>
Thanks to Mike Muuss, future releases of LIBRT now can renumber instanced
region's item numbers.  I have recompiled a version of RIP that uses the
new LIBRT.  You will need a file that contains regular expressions like
those used in ED(1) that will be used to match region path names and remap
their region ids. The file should have the same base name as your database
file but with a ".regexp" suffix (e.g. target.regexp for the file target.g).
Comments may be placed in the regular expression file on lines beginning
with a '#'.  The following is an example:

<p>
#
# Each of the following lines follows the format:
#
#	Regular_Expression	TAB(s)	command SEMICOLON
#
# Examples of valid "command"s for remapping region ids are:
#
#	99	replace old region id with 99 (or any number)
#	+99	increment old region id by 99 (or any number)
#	+uses	increment the old region id by the
#		current instance (use) count
#
# Note that all regular expressions from ed(1), the line editor, are supported
# Note that all commands MUST end with a semicolon ";"
# Note that all backslashes have to be doubled.
# Note that ., \, [, and * are special pattern matching characters
# Blank lines are not significant.
# Commands may extend over multiple lines -- they are terminated only by ";"
#
# Note that the regular expression may specify as much or as little
# of the full path name as needed to get the desired effect.
#
# The order that commands are given is significant, if
# several regular expressions select the same region.
#
# These lines demonstrate all currently supported features.

<p>
# discriminate between each instance of block.r
/b./block\\.r           +uses;
# ditto for sph.r
/s./sph\\.r             +uses;

<p>
# For fourth instance of block.r only, go back and force the region ID to 321.
/b4/block\\.r           321;

<p>
# For the third instance of sph.r only, go back and add 42 to prev. result
/s3/sph\\.r             +42;

<p>
#
# Note that the above database had a tree that looked like:
#
#mged&gt; tree all.g
#all.g/
#        u floor.r/R
#                u floor
#        u b1/
#                u block.r/R
#                        u block
#        u b2/
#                u block.r/R
#                        u block
#        u b3/
#                u block.r/R
#                        u block
#        u b4/
#                u block.r/R
#                        u block
#        u s1/
#                u sph.r/R
#                        u sph
#        u s2/
#                u sph.r/R
#                        u sph
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa07767; 15 May 92 13:15 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab21683; 15 May 92 13:04 EDT
Date:     Fri, 15 May 92 12:53:14 EDT
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.MIL&gt;
To:       "John R. Anderson" &lt;jra@BRL.MIL&gt;
cc:       cad@BRL.MIL
Subject:  Re:  [Paul Tanenbaum: Re: Frame Buffer (fb) Problems]
Message-ID:  &lt;9205151253.aa21373@VMB.BRL.MIL&gt;

<p>
# 	I think "+++paul" has brought up a good point, in fact, why not make
# the lingering frame buffer the default.

<p>
I'll tell you why.  The lingering frame buffer support is an ugly kludge
that has serious consequences for interactive libfb clients like 'lgt' and
'fbed'.  When the libfb/fbclose() function is called from an interactive
program specifying a 'lingering' window, the client gets killed off.  I have
spent mega-hours answering calls from people whose 'lgt' run gets killed
when they close a lingering window.  Note that specifying a remote device
(ie remote-host:/dev/sgipl) or using 'fbserv' is safe because the lingering
window is a remote process, not a child of the client process.

<p>
# How often does one want a frame buffer that disappears as soon as its
# displayed??

<p>
Not very often.  Fbserv is definitely the way to go.  Unfortunately, the
man page didn't get distributed (an oversight apparently), and the inetd
configuration is not part of the automatic BRL-CAD installation as far as
I know.  Getting fbserv properly installed and learning to use it is not
a big deal and is definitely worth the trouble.  There is the drawback
that you can't get a remote fbserv window to resize itself from the client
application, but this usually is not a big hardship for the user.

<p>
-Gary

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa08363; 15 May 92 14:32 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25097; 15 May 92 14:23 EDT
Received: from spark.brl.mil by VMB.BRL.MIL id aa24827; 15 May 92 14:15 EDT
Date:     Fri, 15 May 92 14:14:07 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       cad@BRL.MIL
Subject:  Re:  Frame Buffer (fb) Problems
Message-ID:  &lt;9205151414.aa24717@SPARK.BRL.MIL&gt;

<p>
Gary mentioned a couple of reasons for not defaulting to lingering
windows.  I would add to that that if you are using shared memory
windows for compositing or what have you, you may not want a stack
of windows to pile up on the screen (easy to do).  And while lingering
may be more common for pix-fb, it often isn't correct for other
programs that use frame buffers (take fbzoom for example).  [I have
however considered suggesting that private memory become the default
(rather than shared).  I almost *never* use shared any more.  fbserv
is usually better if you need to do the things shared memory buys you.]

<p>
I think a big problem is that answers to FAQ's like this are very
hard to find in the documentation.  How to use fbserv is almost non
existant (my fault, since I wrote fbserv and didn't "finish" the job),
and there are other charms in there like memory frame buffers with
and without attached displays that let you do some neat things.

<p>
I have wanted to write a tutorial example on using these features
for many months now.  I think having such examples would help first
time users (and even others) a lot.

<p>
- Phil
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa27441; 13 May 91 10:43 EDT
Received: from vmb.brl.mil by VMB.BRL.MIL id ab08285; 13 May 91 10:32 EDT
Received: from wolf.brl.mil by VMB.BRL.MIL id aa08135; 13 May 91 10:22 EDT
Date:     Mon, 13 May 91 10:15:48 EDT
From:     Susan Muuss (VLD/ASB) &lt;sue@BRL.MIL&gt;
To:       cad@BRL.MIL
cc:       sue@BRL.MIL
Subject:  CAD Addition
Message-ID:  &lt;9105131015.aa26183@WOLF.BRL.MIL&gt;

<p>
Today I added a new addition to the converter directory: it is a shell
script that will "compact" mged databases.  It takes two arguments: the
database to be compacted and the new database.  These two arguments must
be different.  The objective is to remove allocated space that remains
when a component is killed.  The program relies on g2asc and asc2g to do
the actual compacting.

<p>
Beware: at this time there is no provision made to cover the following
situation.  When one of the converters skips a solid/solids, then the
database is also "compacted", and the solids skipped by the converters are
are omitted.

<p>
				Cheers,
					Sue

<p>
<hr>
<hr>
Date:     Fri, 5 Jun 92 22:33:59 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
To:       ACST@BRL.MIL
cc:       Jill@BRL
Subject:  progress
Message-ID:  &lt;9206052233.aa10757@WOLF.BRL.MIL&gt;

<p>
Lee just found and fixed a horrible and subtle memory leak in nmg_bool.c

<p>
I just added a "labelvert" command, which labels the vertices of the
vlist of an object with it's model-space coordinates.  Designed to help
understand some of the NMG debugging plots, I suspect that it will
prove valuable to modelers as well.
	-Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa08168; 30 Sep 91 11:19 EDT
Date:     Mon, 30 Sep 91 11:18:08 EDT
From:     "Paul H Deitz: Chief, VLD" &lt;phd@BRL.MIL&gt;
To:       mike@BRL.MIL
cc:       jill@BRL.MIL
Subject:  [Ann Silirie:  BRL TAP Report]
Message-ID:  &lt;9109301118.aa04609@VMB.BRL.MIL&gt;

<p>
FYI.

<p>
phd

<p>
----- Forwarded message # 1:

<p>
Received: from amigo.brl.mil by VMB.BRL.MIL id aa03767; 30 Sep 91 10:19 EDT
Received: from AMIGO.BRL.MIL by AMIGO.BRL.MIL id ac07589; 30 Sep 91 10:11 EDT
Date:     Mon, 30 Sep 91 10:08:20 EDT
From:     Ann Silirie (OD) &lt;silirie@BRL.MIL&gt;
To:       senior-staff@BRL.MIL
Subject:  BRL TAP Report
Message-ID:  &lt;9109301008.aa07517@AMIGO.BRL.MIL&gt;

<p>

                          BRL TAP Report
                          30 September 91

<p>
VULNERABILITY/LETHALITY DIVISION

<p>

<p>

<p>
COMPARISON BETWEEN BLACK HAWK COMPONENTS HIT BY SMALL ARMS PROJECTILES
     IN GRENADA AND GEOMETRIC MODEL INTERROGATION PREDICTIONS

<p>
Interrogations of the three dimensional graphical model for The BLACK HAWK,
UH-60A, were made along the same 7.62mm projectile hit shotlines
encountered during "OPERATION URGENT FURY", the Grenada rescue mission. The
combat damage data results were compared with the predictions from the
Geometric Information For Targets (GIFT) code for the same shotlines
encountered in combat. A total of 26 shotlines were examined
from two helicopters involved in the conflict. The results of the GIFT code
output correlated well with the actual combat damage. The results of this
comparative study will be presented in a paper at the US Army Thirtieth
Operation Research Symposium (AORS XXX) to be held this November at Fort
Lee, VA. POC: Dr. Don Haskell, Ext. 2032.

<p>
  INTERACTIVE SCREEN EDITOR STYLE COMMAND DEVELOPED FOR BRL-CAD'S MGED

<p>
The BRL-CAD, the Army's primary solid modeling system, is used by the BRL,
other government agencies, and private industry.  Its graphics-based user
interface, MGED (Multidevice Graphics EDitor), now can be upgraded to
employ screen editor-like capabilities in editing building blocks (called
regions and groups) of models.  Users can select from a variety of familiar
screen editor environments such as "jove," "emacs," or "vi" to define or
modify region and group definitions. Heretofore, users were forced to
execute the "r" (region) or "g" (group) commands whose data inputs were
completely free of syntax and model construction errors.  The occurrence of
an error in one of these commands often would require the user to
completely retype the command and inputs.  Now the new command "red"
(Region EDitor) will invoke the user's choice of screen editor and allow
the user to modify group and region definitions as easily as editing a
simple file. POC: Donald Haskell, Ext. 2608.

<p>
<hr>
<hr>
Date:     Fri, 19 Jun 92 0:51:14 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
To:       PHD@BRL, Jill@BRL
cc:       ACST@BRL
Subject:  spline editing
Message-ID:  &lt;9206190051.aa15230@WOLF.BRL.MIL&gt;

<p>
For the first evening this week, I actually got to do some programming,
and I finished my first cut at interactive editing of NURB solids
in MGED.  It is now possible to interactively select a surface and
control point, by pointing and clicking with the mouse, and then draging
that control point around on the screen.  The spline surface follows
along beneath it.

<p>
My thanks to Mike Markowski for creating two support subroutines to assist
with the point picking.

<p>
I'd be happy to show it folks.  I've created a really deformed teapot
with almost no effort... You can see for yourself in
wolf:/m/cad/.mged.5d/ugly-teapot.pix (512).

<p>
The user interface needs some refinement before I'd turn anyone loose
on it, but all the pieces are there now.  (Finally).  I've been waiting
years to be able to do this!

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa18884; 5 Aug 92 13:12 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21116; 4 Aug 92 20:50 EDT
Received: from spark.brl.mil by VMB.BRL.MIL id aa20989; 4 Aug 92 20:38 EDT
Date:     Tue, 4 Aug 92 20:35:30 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       "Robert D. LaFollette" &lt;rlafolle@duchamp.nswc.navy.mil&gt;
cc:       cad@BRL.MIL
Subject:  Re:  Image Compression
Message-ID:  &lt;9208042035.aa01939@SPARK.BRL.MIL&gt;

<p>
I agree with Lee Butler.  Factors are:

<p>
1) If there is a lot of constant color, run length encoding (RLE)
   really wins.  See the Utah Raster Toolkit utilities (included
   in BRL-CAD).
2) For general images (e.g. with noise or lots of varying colors),
   general compression techniques (such as compress/uncompress) work
   every bit as well as "image" techniques for the lossless case.
3) Sometimes it helps to do color separations first, and then compress.
4) If you don't need lossless compression, there are some very good
   image oriented compression techniques available (e.g. JPEG).

<p>
Around here we use compress/uncompress a lot.  It's lossless, and
in general works as well or better than RLE (but slower).

<p>
- Phil
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa11157; 19 Aug 92 17:28 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07045; 19 Aug 92 17:22 EDT
Date:     Wed, 19 Aug 92 17:21:04 EDT
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.MIL&gt;
To:       vld-superusers@BRL.MIL
cc:       x11@BRL.MIL, vmb@BRL.MIL
Subject:  VOTE X11 software update
Message-ID:  &lt;9208191721.aa06541@VMB.BRL.MIL&gt;

<p>
Just a warning that I updated VOTE with MIT's official patches 11-13.  I
I have been using this software for several weeks so it should be fine,
but you may notice a large number of Sun4 files being updated via rdist;
it's just a side-effect of rebuilding the core MIT X11R5 distribution.

<p>
Included in this update is the xrolo utility (mimics the functionality
of a rolodex).  I installed this because Jill asked for such a capability,
but I haven't got the time to test it out properly, so use at your own
risk (as usual ;-) and let me know if there are any problems.  I noticed
that it dumps core immediately on Sun3s, but so do many other xview
clients.  Apparently, the xview library has problems there, so I am not
making it available at this point in time on Sun3s.

<p>
Finally, I installed xpa on VOTE; this is the X11 front end to my presented
area, mass, moments and products of inertia, etc. program.  The ray-tracing
back end for xpa is called "paslave" and lives under /usr/vld/bin; it is
typically run on a different host than the X11 part and is installed on
some of the SGI servers.  These programs (xpa/paslave) are experimental
meaning that I have tested the results to the best of my ability, but it
is the user's responsibility to convince himself that the answers are
correct.  I just do not have the resources to come up with a robust set
of test cases with known answers for moments and products of inertia.  It
works for simple test cases (ie a cube), and there is no reason to suspect
that the complexity of the MGED region should make any difference, but
"caveat emptor" anyway.

<p>
-Gary
<hr>
<hr>
Date:     Thu, 3 Sep 92 19:54:09 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
To:       ACST@BRL.MIL
Subject:  MGED anim previews
Message-ID:  &lt;9209031954.aa07269@WOLF.BRL.MIL&gt;

<p>
This evening I have made modifications to MGED to permit the "preview" command
to process "anim", "tree", and "clean" commands from an RT animation script,
and generate the correct display.

<p>
	-M
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa13450; 10 Sep 92 17:38 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02615; 10 Sep 92 17:35 EDT
Received: from vim.brl.mil by VMB.BRL.MIL id aa02605; 10 Sep 92 17:32 EDT
Date:     Thu, 10 Sep 92 17:21:05 EDT
From:     Jodi Robertson &lt;jlrob@BRL.MIL&gt;
To:       cad@BRL.MIL
Subject:  mged and tvtwm
Message-ID:  &lt;9209101721.aa01479@VIM.BRL.MIL&gt;

<p>
CAD world,

<p>
When using mged and attaching sgi (either at the start of editing or
attaching later) mged is (randomly) killed sending me back to my prompt

<p>
I am using the latest (?) version of mged
BRL-CAD Release 4.1   Graphics Editor (MGED)
    Thu Sep  3 13:10:56 EDT 1992, Compilation 4
    stay@wildcat:/n/wolf/m/dist4.1/mged

<p>
and running tvtwm with IRIX 4.0.5

<p>
Has anyone seen this problem and have a solution???????

<p>
	thanks
	jodi
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa14387; 10 Sep 92 20:11 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03733; 10 Sep 92 19:36 EDT
Date:     Thu, 10 Sep 92 19:26:21 EDT
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
To:       Jodi Robertson &lt;jlrob@BRL.MIL&gt;
cc:       cad@BRL.MIL
Subject:  Re:  mged and tvtwm
Message-ID:  &lt;9209101926.aa03711@VMB.BRL.MIL&gt;

<p>
&gt;When using mged and attaching sgi (either at the start of editing or
&gt;attaching later) mged is (randomly) killed sending me back to my prompt

<p>
Mike Markowski also noticed this.  On the occasions it's been noticed, it
seems to be related to an unusual state of the graphics engine.  Applying the
"Vulcan Death Grip" (simultaneous Lctrl,Lshift,F12,keypad-/) to reset the
graphics hardware seems to correct the problem.  If you can come up with a
repeatable test case, please let us know.

<p>
Lee A. Butler
Ballistic Research Laboratory		Internet: butler@brl.mil
Aberdeen P.G., MD 21005-5066		Phone: (410) 278-9200
<hr>
<hr>
Date:     Tue, 15 Sep 92 1:27:38 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
To:       Edwin O. Davisson &lt;davisson@brl.mil&gt;
cc:       ACST@BRL.MIL
Subject:  Re: [Edwin O. Davisson: NMG's]
Message-ID:  &lt;9209150127.aa02180@WOLF.BRL.MIL&gt;

<p>

<p>
The short answer is that you didn't miss anything while you were sick.
I hope you are feeling better now!

<p>
The files to read in preparation for doing something with NMGs are
h/nmg.h, librt/nmg_*.c, librt/g_nmg.c, and mged/dodraw.c

<p>
For an example of some code that creates an NMG object, you might
examine librt/g_arb.c: rt_arb_tess() and librt/g_ell.c: rt_ell_tess().
I don't promise that either are "clean" or the "best" way to accomplish
that task, but they arn't bad, and work.

<p>
You are welcome to consider either the Release 4.0 versions, or the
latest sources from wolf:/m/cad, although I note that the later may be
in a state of disrepair on occasion, as Lee and I are working hard on
the code, between briefings, TDY, and other excitement provided from on
high.

<p>
After you've spent a little while looking around, it would probably be
appropriate to get together and chat for an hour or two some afternoon,
to answer whatever questions have come up.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa04666; 9 Oct 92 1:14 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24066; 9 Oct 92 1:09 EDT
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa24060; 9 Oct 92 1:05 EDT
Date:     Fri, 9 Oct 92 1:05:08 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       "Bruce A. Rickter" &lt;bar@BRL.MIL&gt;
cc:       cad@BRL.MIL
Subject:  Re: bw-imp
Message-ID:  &lt;9210090105.aa04650@WOLF.BRL.MIL&gt;

<p>

<p>
Bruce writes -

<p>
&gt;   What do the options  -s squaresize, -w width, and
&gt;    -h height do?

<p>
They specify the size of the input file.  For a more full description
of these options (which show up on almost every image processing command
in BRL-CAD), run "man brlcad".  That man page documents the overall
conventions for command line options.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa01084; 29 Jul 92 13:51 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id ai00267; 29 Jul 92 13:29 EDT
Received: from vim.brl.mil by VMB.BRL.MIL id ab00224; 29 Jul 92 13:22 EDT
Date:     Wed, 29 Jul 92 13:17:29 EDT
From:     Jim Hunt &lt;jehunt@BRL.MIL&gt;
To:       Pat Gatewood &lt;pat@helga.setd-ctl.nawcad.navy.mil&gt;
cc:       cad@BRL.MIL
Subject:  Re:  Trouble making edpix on sgi
Message-ID:  &lt;9207291317.aa06485@VIM.BRL.MIL&gt;

<p>
I can not reproduce this error on Irix 4.0.5, but do recall the exact
same trouble when we were running 4.0.1.  The fix is to put the Font
Manager Library ( libfm_s.a ) before the other libraries:

<p>
./cad/edpix/Cakefile:
20c20
&lt;       CC LDFLAGS -o edpix OBJ LIB_PRE''LIBRLE -lgl_s -lfm_s LIBES
---
&gt;       CC LDFLAGS -o edpix OBJ -lfm_s LIB_PRE''LIBRLE -lgl_s LIBES

<p>
I believe the C compiler is going through some groing pains?  At leaset
it has had other difficulties between 4.0.1 and 4.0.5 so for now I will
blame it.  Let me know if the problem persists.

<p>
-jim Hunt
<hr>
<hr>
Received: from wumpus.brl.mil by WOLF.BRL.MIL id aa21046; 28 Oct 92 14:31 EST
Date:     Wed, 28 Oct 92 14:29:19 EST
From:     Carl Moore (VLD/VMB) &lt;cmoore@BRL.MIL&gt;
To:       acst@BRL.MIL, pjt@BRL.MIL
cc:       cmoore@BRL.MIL
Subject:  noise around the edges?
Message-ID:  &lt;9210281429.aa18179@WUMPUS.BRL.MIL&gt;

<p>
I had sent a previous message to PJT about this.  Here, I am providing
a sample run.  Sending to "cad" reaches too many people at this time;
besides, people outside the former BRL can't get at this sample.

<p>
On WUMPUS, look up the directory /vld/cmoore/CELLFBTEST , and run the
executable (user-readable) file "runstream".  For starters: Why do I
get white space instead of red space (the latter indicating a value of 1)
at (y = -40) x=+16,+12,-32,-40?
x is the first field, y is the 2nd field, and I am plotting the 3rd field.
<hr>
<hr>
Received: from wumpus.brl.mil by WOLF.BRL.MIL id aa00320; 29 Oct 92 15:43 EST
Date:     Thu, 29 Oct 92 15:39:38 EST
From:     Carl Moore (VLD/VMB) &lt;cmoore@BRL.MIL&gt;
To:       acst@BRL.MIL, pjt@BRL.MIL
Subject:  [Carl Moore: noise around the edges?]
Message-ID:  &lt;9210291539.aa23543@WUMPUS.BRL.MIL&gt;

<p>

<p>
Disregard this message (and I am deleting the copy to myself).
Field number 3 is the third field AFTER the x and y columns.
In other words, I was comparing field 3 to field 1.

<p>
----- Forwarded message # 1:

<p>
Date:     Wed, 28 Oct 92 14:29:19 EST
From:     Carl Moore (VLD/VMB)  &lt;cmoore@BRL&gt;
To:       acst@BRL.MIL, pjt@BRL.MIL
cc:       cmoore@BRL
Subject:  noise around the edges?
Message-ID:  &lt;9210281429.aa18179@WUMPUS.BRL.MIL&gt;

<p>
I had sent a previous message to PJT about this.  Here, I am providing
a sample run.  Sending to "cad" reaches too many people at this time;
besides, people outside the former BRL can't get at this sample.

<p>
On WUMPUS, look up the directory /vld/cmoore/CELLFBTEST , and run the
executable (user-readable) file "runstream".  For starters: Why do I
get white space instead of red space (the latter indicating a value of 1)
at (y = -40) x=+16,+12,-32,-40?
x is the first field, y is the 2nd field, and I am plotting the 3rd field.

<p>
----- End of forwarded messages
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa04877; 2 Nov 92 17:58 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22195; 2 Nov 92 16:31 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa22067; 2 Nov 92 16:16 EST
Date:     Mon, 2 Nov 92 16:12:33 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       "Kenneth H. Fielding" &lt;kfieldin@afit.af.mil&gt;
cc:       cad@BRL.MIL
Subject:  Re: animation for brl-cad
Message-ID:  &lt;9211021612.aa03696@WOLF.BRL.MIL&gt;

<p>

<p>
It seems like external interest in animation using BRL-CAD is suddenly
picking up:

<p>
&gt; From: "Kenneth H. Fielding" &lt;kfieldin@afit.af.mil&gt;
&gt;
&gt; I would like to generate say a 10 frame sequence where I can define
&gt; scale, orientation, and position for the object in each frame.  The
&gt; frames can then be ganged together to make a "movie".
&gt;
&gt; what is the easiest and most straight forward way to do this in
&gt; either "rt" or "lgt"?

<p>
&gt; From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.MIL&gt;
&gt;
&gt; I don't know the easiest way.  Hopefully, if tools exist to do in-betweening
&gt; or other useful steps in generating smooth animation sequences, someone else
&gt; will speak up.  I recall some buggy frame-interpolation software that used
&gt; to be available at BRL, but it was never made available for general use.

<p>
I'm not sure what software Gary is making reference to, but in Release
4.0 you will find the two primary tools that I have used for making
animations:  TABINTERP and TABSUB.  They don't have manual pages at the
moment.

<p>
TABINTERP is a table-based interpolator that can take an arbitrary
collection of columns from an arbitrary number of input files, and
resamples them using a selection of interpolators (including spline).

<p>
TABSUB is a macro processor especially suited for generating RT
animation scripts from the output of TABINTERP.

<p>
Keyframes can be specified using MGED, by hand, or using an external
program.  I've done it all three ways.

<p>
Once an animation script has been prepared, it can be fed to either
RT or REMRT on stdin by giving the -M flag on the commandline.  All
frames will be computed in sequence, with "checkpoint-restart" handled
automaticly, so that the machine going down won't cost you more than a
few pixels of the final result.

<p>
Note that the RT animation script facility can BOTH (a) move the
eyepoint around stationary geometry, and (b) articulate the geometry
at any number of arcs in the database DAG (tree).  For example, the eye
(camera) could by flying, while a rotation was being superimposed on the
arc tank.g/turret.g.

<p>
Lee Butler has a draft of a paper on how to use this capability.  It
is not complete, but should serve as a useful baseline.  Contact him
at &lt;butler@brl.mil&gt;.

<p>
Also note that there is a tutorial session on using this capability
being given by Chris Johnson at the BRL-CAD Users Conference this week.
Contact the conferenct at 800-466-4862 for info.  While I have not seen
his presentation materials, he has produced quite a number of successful
animation sequences using the RT animation capability, so his talk
should be quite informative.

<p>
I'm sorry that there isn't more written about this stuff, but writing
takes time.  After you have looked over the intro materials, I'd be
happy to send you an example of a simple animation.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa15738; 11 Nov 92 15:15 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08475; 11 Nov 92 14:25 EST
Received: from wharf.brl.mil by VMB.BRL.MIL id aa08473; 11 Nov 92 14:21 EST
Received: from ti.com by WHARF.BRL.MIL id aa20376; 11 Nov 92 14:36 EST
Received: from mk1501.dseg.ti.com ([128.247.206.175]) by ti.com with SMTP
	(5.59/LAI-3.2) id AA07893; Wed, 11 Nov 92 13:38:48 CST
Received: from medusa.dseg.ti.com by mk1501.dseg.ti.com with SMTP
	(5.59/LAI-3.2) id AA10620; Wed, 11 Nov 92 13:37:46 CST
Received: from ares.dseg.ti.com by medusa.dseg.ti.com (4.1/SMI-4.1)
	id AA14172; Wed, 11 Nov 92 13:37:26 CST
Date: Wed, 11 Nov 92 13:37:26 CST
From: harry campbell &lt;harry@medusa.dseg.ti.com&gt;
Message-Id: &lt;9211111937.AA14172@medusa.dseg.ti.com&gt;
To: cad@BRL.MIL
Subject: perspective switch for MGED

<p>
At the BRLCAD conference it was demonstrated that their is a toggle switch
for perspective viewing in MGED.  On the SGI machines I beleive it was F2
or F3.  One of the other keys could then be used to flip through the
major perspective angles (90,60,30).

<p>
I have tried to put MGED into perspective viewing mode, and it doesn't seem to
work.  We have BRLCAD running on SPARC IPX.  Is perspective viewing supported
for the SUN running X?  If so, what is the keystroke to turn it on?

<p>
Harry Campbell
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa16782; 11 Nov 92 20:11 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09563; 11 Nov 92 19:26 EST
Date:     Wed, 11 Nov 92 19:18:33 EST
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
To:       harry campbell &lt;harry@medusa.dseg.ti.com&gt;
cc:       cad@BRL.MIL
Subject:  Re:  perspective switch for MGED
Message-ID:  &lt;9211111918.aa09557@VMB.BRL.MIL&gt;

<p>
Alas, I believe the perspective function button is only available on the SGI
at the moment.

<p>
Lee A. Butler
U.S. Army Research Laboratory			Internet: butler@brl.mil
Aberdeen Proving Ground, MD  21005-5068		Phone: (410) 278-9200
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa21107; 16 Nov 92 15:49 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11754; 16 Nov 92 15:21 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa11664; 16 Nov 92 15:14 EST
Date:     Mon, 16 Nov 92 15:36:29 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       Support@results.com
cc:       cad@BRL.MIL, harry campbell &lt;harry@medusa.dseg.ti.com&gt;
Subject:  Re: perspective switch for MGED
Message-ID:  &lt;9211161536.aa21053@WOLF.BRL.MIL&gt;

<p>

<p>
&gt; The perspective viewing mode is not available under X.  The reason is that
&gt; the perspective is generated in the view module of mged.  Under the sgi
&gt; view module each vector is passed through a (hardware) matrix multiply.
&gt; There is no such manipulation in the X window support.

<p>
The details here are incorrect. In Release 4.0, the perspective is
generated in the SGI-specific display manager module mged/dm-4d.c (*not*
the view module).  Both the SGI and the X display managers already
transform each vector by a 4x4 transform matrix.  But the conclusion is
right -- in Release 4.0, there is no perspective viewing on the X
interface.

<p>
However, in the development version of MGED, perspective support has
been pushed up into the "top half" of the display interface, and thus
automaticly operates properly on X displays, and all other displays.

<p>
No function key has been assigned on the X display yet, but keyboard
commands can be used to assign the viewing angle, like:

<p>
	set perspective=90
and
	set perspective=42.5

<p>
It can be turned off (orthoview) with

<p>
	set perspective=0

<p>
Something to look forward to in the next release.
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa27709; 13 Nov 92 11:08 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25393; 13 Nov 92 10:11 EST
Received: from worm.brl.mil by VMB.BRL.MIL id aa25316; 13 Nov 92 10:05 EST
Date:     Fri, 13 Nov 92 10:16:14 EST
From:     "Jill H. Smith, Ch., Vuln. Meth. Br." &lt;jill@BRL.MIL&gt;
To:       cad@BRL.MIL
cc:       jleonard@mbv.mbvlab.wpafb.af.mil
Subject:  [Jim Leonard:  X term with BRLCAD]
Message-ID:  &lt;9211131016.aa19779@WORM.BRL.MIL&gt;

<p>
All,

<p>
Can anyone help Jim get is display diplaying?

<p>
Jill

<p>
----- Forwarded message # 1:

<p>
Received: from wharf.brl.mil by WORM.BRL.MIL id aa19456; 13 Nov 92 9:59 EST
Received: from fivs01.flight.wpafb.af.mil by WHARF.BRL.MIL id aa08436;
          13 Nov 92 9:40 EST
Received: from fovea.mbvlab.wpafb.af.mil ([134.131.203.6]) by mbv (4.1/SMI-4.1)
	id AA13590; Fri, 13 Nov 92 09:39:04 EST
Date: Fri, 13 Nov 92 09:39:04 EST
From: Jim Leonard &lt;jleonard@mbvlab.wpafb.af.mil&gt;
Message-Id: &lt;9211131439.AA13590@mbv&gt;
To: jill@BRL.MIL
Subject: X term with BRLCAD

<p>
Jill,
I'm Jim Leonard and I talked with you at the conference last week.  I am
running the CAD on a Sun 4 using X11R4 on a Mac running AUX.  Running mged
everything is fine until I do a ray trace.  The frame buffer opens and stays
but the window stays black.  I have:
setenv DISPLAY to my Mac computer
setenv FB_FILE /dev/Xl

<p>
Does anyone have any ideas what I need to do to get the frame buffer displayed?
Thanks
Jim Leonard
jleonard@mbv.mbvlab.wpafb.af.mil
phone DSN 785-1115 or commercial (513)255-1115

<p>
----- End of forwarded messages
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa28246; 13 Nov 92 12:30 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26309; 13 Nov 92 11:23 EST
Received: by VMB.BRL.MIL id aa26140; 13 Nov 92 11:13 EST
Date:     Fri, 13 Nov 92 11:11:28 EST
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
To:       "Jill H. Smith, Ch., Vuln. Meth. Br." &lt;jill@BRL.MIL&gt;
cc:       cad@BRL.MIL, jleonard@mbv.mbvlab.wpafb.af.mil
Subject:  Re:  [Jim Leonard: X term with BRLCAD]
Message-ID:  &lt;9211131111.aa26126@VMB.BRL.MIL&gt;

<p>
&gt;everything is fine until I do a ray trace.  The frame buffer opens and stays
&gt;but the window stays black.  I have:
&gt;setenv DISPLAY to my Mac computer
&gt;setenv FB_FILE /dev/Xl

<p>
I'm just guessing, but it could be that you need to make sure the mouse
pointer moves into the framebuffer window.  Since the X server will probably
need to load a new color map for that window, you may not see anything until
the mouse is in the window.

<p>
Taking another stab in the dark, can you display one of the pix files that
came with BRL-CAD?  Try:
	 pix-fb -F /dev/Xl  brlcad/pix/moss.pix

<p>
Since I don't have a Mac to try this on, I can't offer much else.

<p>
Lee
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa29993; 13 Nov 92 14:56 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28268; 13 Nov 92 14:16 EST
Received: from wharf.brl.mil by VMB.BRL.MIL id aa28178; 13 Nov 92 14:08 EST
Received: from relay2.UU.NET by WHARF.BRL.MIL id aa10614; 13 Nov 92 14:16 EST
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
	(5.61/UUNET-internet-primary) id AA11419; Fri, 13 Nov 92 14:16:18 -0500
Received: from results.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 141114.2695; Fri, 13 Nov 1992 14:11:14 EST
Received: from localhost by results.com (5.64/A/UX-AMR-1.0)
	id AA22820; Fri, 13 Nov 92 14:53:53 EST
Message-Id: &lt;9211131953.AA22820@results.com&gt;
Date: Fri, 13 Nov 1992 14:54:00 -0800
To: cad@BRL.MIL, "Jill H. Smith, Ch., Vuln. Meth. Br." &lt;jill@BRL.MIL&gt;
From: Support@results.com
Subject: Re: [Jim Leonard:  X term with BRLCAD]
Cc: jleonard@mbv.mbvlab.wpafb.af.mil

<p>
&gt;To: jill@BRL.MIL
&gt;Subject: X term with BRLCAD
&gt;
&gt;Jill,
&gt;I'm Jim Leonard and I talked with you at the conference last week.  I am
&gt;running the CAD on a Sun 4 using X11R4 on a Mac running AUX.  Running mged
&gt;everything is fine until I do a ray trace.  The frame buffer opens and stays
&gt;but the window stays black.  I have:
&gt;setenv DISPLAY to my Mac computer
&gt;setenv FB_FILE /dev/Xl
&gt;
&gt;Does anyone have any ideas what I need to do to get the frame buffer displayed?
&gt;Thanks
&gt;Jim Leonard
&gt;jleonard@mbv.mbvlab.wpafb.af.mil

<p>
Jim,

<p>
The most likely problem you are having with your X display under A/UX
(assuming that you are using MacX) is that you are using the wrong screen.
The method that I use is:
        Make a version of libfb under A/UX that has X support compiled in.
                (There is a #if 0/1 in /m/cad/Cakefile.defs to do this)
        cd /m/cad/libfb
        cake clean; cake libfb.a
        cd ../fbserv
        cake
        (install fbserv)
        edit /m/cad/Cakefile.defs to change the frame buffer support to no
X)
        cd /m/cad/libfb;cake clean; cake libfb.a

<p>

<p>
Once fbserv is installed, try the following:
        DISPLAY=localhost:0.2;export DISPLAY
        fbserv -F/dev/X 0&
on your sun:
        FB_FILE=mac_name:0;export FB_FILE
        pix-fb /m/cad/pix/world.pix

<p>
This should work.  Be aware that color support is not very good for X yet.

<p>
Chris Johnson
--
Support@results.com                              1-800-497-6165
BRL-CAD Support Group.  Installations, technical support, animations,
printing, plus more.

<p>
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa04279; 18 Nov 92 22:35 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08369; 18 Nov 92 22:26 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa08365; 18 Nov 92 22:23 EST
Date:     Wed, 18 Nov 92 22:27:14 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  &gt;9999 solids for VDECK
Message-ID:  &lt;9211182227.aa03665@WOLF.BRL.MIL&gt;

<p>
Responding to the suggestion of Tom Sullivan of SANDIA at the recent
BRL-CAD Users Conference, I have modified the development copy of
VDECK to support the creation of .cg files containing more than 9999
solids.  This can be important for the calculation of radar signatures
of certain large geometry files on Sandia's parallel machines.

<p>
Here is the RCS log entry:

<p>
date: 92/11/18 22:21:02;  author: mike;  state: Exp;  lines added/del: 20/6
Added improvement suggeted by Tom Sullivan of Sandia to
permit solids with numbers &gt; 9999 to be referenced by
a subtraction operation in the region table, by
substituting operator "nn#" for "  -#".

<p>
If you need this modification to support your work, please drop me a line
and I'll E-mail it to you.

<p>
	Best,
	 -Mike

<p>
PS:  Thanks to Harry Reed of GSI for the use of the Havoc 'chopper
model, which I instanced 8 times to make a suitably large database to
test the &gt;9999 solids condition.
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa10101; 14 Dec 92 15:48 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25706; 14 Dec 92 15:37 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa25651; 14 Dec 92 15:28 EST
Date:     Mon, 14 Dec 92 15:30:37 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  libfb autosize
Message-ID:  &lt;9212141530.aa09776@WOLF.BRL.MIL&gt;

<p>
Following up on a remark that Chris Johnson made at the BRL-CAD User's
Conference, and motivated by having to process some SIGS images, I have
expanded the autosize functionality of LIBFB (usually obtained with the
"-a" flag on programs) so that if the image is exactly square (of any
dimension), it will autosize.

<p>
This means that, e.g., 1800x1800 or 200x200 images or 52x52 images
will all autosize, without having to add those sizes to the
table.

<p>
Something to look forward to in the next release.
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa08776; 6 Jan 93 23:43 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07211; 6 Jan 93 23:23 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id aa07199; 6 Jan 93 23:09 EST
Date:     Wed, 6 Jan 93 23:13:50 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  'f' option to /dev/ab (LIBFB)
Message-ID:  &lt;9301062313.aa08331@WOLF.BRL.MIL&gt;

<p>
This evening, I added an 'f' option to the LIBFB routine if_ab.c, so
that instead of writing .YUV data over the EtherNet to a network
connected Abekas, the .YUV data is written into a disk file.

<p>
For example, the command:

<p>
	pix-fb -F /dev/abovf@prefix#42 dragon.pix

<p>
will create the disk file:

<p>
	prefix42.yuv

<p>
When the 'f' flag is given, what is usually the host name (following
the '@') is now interpreted as a prefix string, which may include
slashes to indicate a full path.  The suffix of ".yuv" is always
provided.

<p>
Similarly, the command

<p>
	fb-pix -F /dev/abvf@/tmp/#42 newfile.pix

<p>
will read the (framebuffer) disk file "/tmp/42.yuv" and store it in
"newfile.pix".

<p>
This new option should allow more efficient use of disk space when
creating animations destined exclusively for an Abekas, because
.YUV files are smaller than .PIX files.  Also, if frames are stored
in .YUV format, they can be bulk loaded to the Abekas without having
to pay the 4-seconds per frame processing time for converting .PIX to
.YUV.  The transmission then becomes simply:

<p>
	rcp *.yuv abekas:

<p>
This also makes it easy to write Abekas backup/restore formatted 8mm
Exabyte tapes directly from the UNIX host.  The Abekas loads images
about twice as fast from the Exabyte as it does over the Ethernet.
That, plus the advantage of getting a tape backup copy as a "free"
by-product, makes this attractive for longer animations.  More on this
in some future note.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa09594; 7 Jan 93 2:10 EST
Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07211; 6 Jan 93 23:23 EST
Received: from wolf16.brl.mil by VMB.BRL.MIL id ab07199; 6 Jan 93 23:09 EST
Date:     Wed, 6 Jan 93 23:20:53 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  /dev/ab addition
Message-ID:  &lt;9301062320.aa08721@WOLF.BRL.MIL&gt;

<p>
The line that read:

<p>
        fb-pix -F /dev/abvf@/tmp/#42 newfile.pix

<p>
is likely to be more satisfying if it reads:

<p>
        fb-pix -w720 -n486 -F /dev/abvf@/tmp/#42 newfile.pix

<p>
so that all the pixels are converted.  (The default is -s512, which
does not process all 720 pixels across).

<p>
		Best,
		 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa11334; 20 Jan 93 13:59 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa20768; 20 Jan 93 13:30 EST
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa20644; 20 Jan 93 13:23 EST
Date:     Wed, 20 Jan 93 13:18:39 EST
From:     Mike Markowski &lt;mm@BRL.MIL&gt;
To:       cad@BRL.MIL
Subject:  NMG Polygon Extruder
Organization:  US Army Research Laboratory
Message-ID:  &lt;9301201318.aa10569@WOLF.BRL.MIL&gt;

<p>
Many brl-cad users have been interested in extruding into 3d an arbitrary
polygon or in adding thickness to faceted objects.

<p>
Yesterday I finished a subroutine that given an NMG face and a vector, will
extrude the face based on the direction and magnitude of the vector.  The
routine handles a single face of one or more loops.  This is the 1st step
towards a routine allowing general (multiple face) extrusion of faceted
objects.

<p>
Stay tuned,
Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa09877; 20 Jan 93 11:27 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa15940; 20 Jan 93 10:08 EST
Received: from waffle.brl.mil by WALRUS.BRL.MIL id aa15805; 20 Jan 93 10:01 EST
Date:     Wed, 20 Jan 93 9:57:35 EST
From:     Paul Stay &lt;stay@BRL.MIL&gt;
To:       cad@BRL.MIL
cc:       phd@BRL.MIL, jill@BRL.MIL
Subject:  Hidden Line Drawings and Plot Files
Message-ID:  &lt;9301200957.aa04781@WAFFLE.BRL.MIL&gt;

<p>

<p>
At a recent meeting it was asked how to produce HPGL or Postscript
files for line plots (hidden line drawings). Since it seems to of general
interest in the community I thought that I would give a brief description
on how to do this.

<p>
The first phase is to get a plot file made. I will use the m35 truck
found in the database to illustrate on how this is done.

<p>
To get a top view of the m35 truck made into a plot file
you can use the rthide command.
	rthide -o top.pl -s 1024 -a 90 -e 90 m35.g component

<p>
This creates an Extended Unix Plot file, the extended Plot format allows
for 3D data, color, space bounding boxes, etc. You can look in the libplot
directory for more info.

<p>
We now need to Rotate the plotfile, Scale it, convert it to the standard
Unix Plot format.

<p>
	plrot -a 90 -e 90 -g top.pl | pl-pl -S &gt; top2.pl

<p>
The plot file is now ready to convert to a number of different formats
and there are several converters,
	pl-tek		Plot to Tektronix
	pl-ps		Plot to Postscript
	pl-hpgl		Plot to HP GL format
	pl-fb		Plot to BRLCAD Frame buffer

<p>
If you want hpgl then do

<p>
	pl-hpgl &lt; top2.pl &gt; top.hpgl

<p>
I tested the above including sending the top.hpgl to our
Tektronix Phaser III in hpgl mode.

<p>
You will want to look at the man pages for details on each of the
above programs.

<p>
The following script can be used to generate a side view of the database

<p>
and can be called by

<p>
	side.sh m35.g component

<p>
----------------------------- side.sh ---------------------------

<p>
#!/bin/sh

<p>
PATH=/usr/brlcad/bin

<p>
rthide -s 512 -a 90 -e 0 $1 $2 | plrot -a 90 -e 0 -g \
	| pl-pl -S | pl-hpgl

<p>
-----------------------------------------------------------------

<p>
Hope this helps.

<p>
	-Paul
<hr>
<hr>
Date:     Mon, 25 Jan 93 11:48:39 EST
From:     Mike Muuss  &lt;mike@brl&gt;
To:       ACST@BRL.MIL
cc:       Jill@BRL.MIL, PHD@BRL.MIL
Subject:  Another NMG note
Message-ID:  &lt;9301251148.aa10034@WOLF.BRL.MIL&gt;

<p>
One major item which I forgot to mention on Friday was the creation
of a new support module, nmg_visit.c, which handles recursive
descent of the NMG data structures, invoking caller-provided
functions at relevant stops along the way.  This makes tasks like
"visit all the vertices" (which can be reached 5 different ways)
very simple to program.
	Best,
	 -Mike
<hr>
<hr>
Date:     Thu, 18 Feb 93 6:16:07 EST
From:     Mike Muuss  &lt;mike@brl&gt;
To:       Jill@BRL, ACST@BRL, Davisson@BRL
Subject:  2d NMG intersector
Message-ID:  &lt;9302180616.aa20220@WOLF.BRL.MIL&gt;

<p>
This evening I got the 2D (co-planar face) code to do it's first
test case successfully, which is very encouraging.

<p>
Along the way I re-learned that eu-&gt;eumate_p-&gt;vu_p is not at all
the same as RT_LIST_PNEXT_CIRC(edgeuse,eu)-&gt;vu_p -- the vu's UP pointer
is in the faceuse of *opposite* orientation in the first case, and
the correct orientation in the second case.  Important difference,
even if the first formula is easier to type.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa27244; 19 Feb 93 1:40 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa12809; 19 Feb 93 1:23 EST
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa12807; 19 Feb 93 1:20 EST
Date:     Fri, 19 Feb 93 1:19:13 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       joe edward meier &lt;jem@bruker.com&gt;
cc:       CAD@BRL.MIL
Subject:  Re: Getting some example models
Message-ID:  &lt;9302190119.aa27182@WOLF.BRL.MIL&gt;

<p>

<p>
&gt;    I just got my 4.0 documentation, and after just scanning through
&gt; it looks pretty impressive.  I think everyone did a good job.

<p>
Thanks!  It's also good to know that the boxes are making it through
the mail, too.

<p>
&gt; On to the actual topic.  I was very impressed by the complexity of
&gt; some of the models displayed (created in mged), and I thought it would
&gt; be a big help in learning how to design complex models if I had one
&gt; or two of these to play with and see how they were built.

<p>
Probably the best way to gear up a staff for a large model building
task would be to contact one of several companies which provide BRL-CAD
training courses, and take a class.  CSG model building is a little
bit different than traditional modeling, and the current documentation
is not oriented towards this.

<p>
A lack which we are aware of.  There are plans afoot to have more
documentation created, but it won't be in the hands of end-users for
at least another year.

<p>
&gt; So, is
&gt; it possible to get via ftp some of these models, like the M1A1
&gt; and/or the Bradley.

<p>
There are some restrictions on what geometric models can be distributed,
and there is a small handling fee associated with acquiring each model
and it's supporting documentation.  Please contact Keith Applin at
N/A-N/A-NANA &lt;xxx@xxx.xxx&gt; for information about what models are
available, and what the distribution arrangements are.

<p>
On the other hand, you might want to examine the "db/" directory in
BRL-CAD Release 4.0 -- it contains a railroad tank car (db/tank_car.asc)
and a Havoc 'chopper (db/havoc.asc), both very nice looking models
which were provided courtesy of Harry Reed, Geometric Solutions Inc.

<p>
	Best,
	 -Mike Muuss

<p>
	  The US Army Research Laboratory
	  APG, MD  21005-5068
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa27483; 19 Feb 93 2:33 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa12870; 19 Feb 93 2:04 EST
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa12864; 19 Feb 93 2:00 EST
Date:     Fri, 19 Feb 93 1:56:19 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       joe edward meier &lt;jem@bruker.com&gt;
cc:       CAD@BRL.MIL
Subject:  Re: Does the ev command work in 4.0
Message-ID:  &lt;9302190156.aa27299@WOLF.BRL.MIL&gt;

<p>

<p>
&gt; From: joe edward meier &lt;jem@bruker.com&gt;
&gt;
&gt;   Does the "ev" command work in the 4.0 version of meged.  When I
&gt; use the command the whole program quits.

<p>
In the 4.0 Release, the "ev" command does occasionally work, but only on
exceedingly simple cases.  It is provided more so that interested
developers can examine the code to learn more about how the NMG
routines can be used, than to provide an end-user service.

<p>
We felt it important to ship Release 4.0 with a non-working NMG library
so that users could take advantage of the many other improvements and
optimizations it contains, rather than delaying the rest of the software
a substantial length of time (years, as it has turned out). The
maintenance release will provide a functional NMG library.

<p>
Expect this pattern to recur.  Release 5.0 will probably have initial
support for trimmed-NURBS (t-NURBS), and in Release 5.1 the t-NURBS
support will be complete.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa11367; 20 Feb 93 6:45 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa25352; 20 Feb 93 6:15 EST
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa25337; 20 Feb 93 6:13 EST
Date:     Sat, 20 Feb 93 6:02:58 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  nmg_esplit() arg change
Message-ID:  &lt;9302200602.aa10899@WOLF.BRL.MIL&gt;

<p>
In preparation for doing code review on the first set of modules which
comprise the NMG support library, I encountered the routine nmg_esplit(),
the function of which was difficult to describe.

<p>
To make the function more precise, easier to understand, and much easier
for calling routines to use, the second argument was changed from
being an edge to an edgeuse (of that edge), and the return code was
changed from being an edge to an edgeuse, also.

<p>
The new calling sequence is:

<p>
struct edgeuse *
nmg_esplit(v, eu)
struct vertex	*v;
struct edgeuse	*eu;
{
}

<p>
This routine was only used by internal routines, and in only a few
places, so the change was not disruptive.  Furthermore, in every
instance, the previous call had been

<p>
	nmg_esplit( v, eu-&gt;e_p );

<p>
so changing that to be

<p>
	nmg_esplit( v, eu );

<p>
was no hardship.  Since this routine is mentioned in the documentation,
there is a slight chance that other code developers have written
something which makes use of it.  That is the purpose of this message,
to warn of the impending change.

<p>
Both the compile time argument checking (on ANSI C compilers) and the
customary NMG library's run-time argument checking (on all systems)
will assist in swiftly isolating any non-library code which needs to
be modified to deal with this change.

<p>
	Best,
	 -Mike

<p>
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa14914; 23 Feb 93 16:53 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa23400; 23 Feb 93 16:29 EST
Received: from wumpus.brl.mil by WALRUS.BRL.MIL id aa23398; 23 Feb 93 16:26 EST
Date:     Tue, 23 Feb 93 16:18:50 EST
From:     Carl Moore (VLD/VMB) &lt;cmoore@BRL.MIL&gt;
To:       yih &lt;ged@BRL.MIL&gt;
Subject:  cross section areas
Message-ID:  &lt;9302231618.aa17803@WUMPUS.BRL.MIL&gt;

<p>
A question reached me about cross-section area in mged, and I
was able to provide only a partial answer (i.e., I don't know
of being able to cut a plane through a target and get the area
showing up on that plane).

<p>
The partial answer was that I can do the "area" command within
mged and get the presented area of the view that I am currently
displaying.
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa00655; 24 Feb 93 13:13 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa27564; 24 Feb 93 10:31 EST
Date:     Wed, 24 Feb 93 10:20:27 EST
From:     "Edwin O. Davisson" (BVLD/VMB) &lt;davisson@BRL.MIL&gt;
To:       JOHN H SUCKLING &lt;john@BRL.MIL&gt;
cc:       Carl Moore &lt;cmoore@BRL.MIL&gt;, yih &lt;ged@BRL.MIL&gt;
Subject:  Re:  cross section areas
Message-ID:  &lt;9302241020.aa27130@WALRUS.BRL.MIL&gt;

<p>

<p>
	The presented area calculated with a view normal to the cutting
plane would be the area of the cross-section provided that the projection
of the rest of the object does not spill into places outside of the
2-d regions defined by the planar cut.

<p>
	There may be elegant MGED solutions to this in place, but I
don't know of them.

<p>
	If you are planning to get a good approximation--one which
avoids the problem mentioned above, you can make a second planar cut
parallel and near to the first and subtract the backside of the region
before making the presented area calculation. That will improve your
chances of getting the area of the slice of baloney of interest.

<p>
					Ed
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id ac00655; 24 Feb 93 13:13 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id ab28267; 24 Feb 93 11:22 EST
Received: from wumpus.brl.mil by WALRUS.BRL.MIL id aa28242; 24 Feb 93 11:19 EST
Date:     Wed, 24 Feb 93 11:12:17 EST
From:     Carl Moore (VLD/VMB) &lt;cmoore@BRL.MIL&gt;
To:       davisson@BRL.MIL
cc:       yih &lt;ged@BRL.MIL&gt;
Subject:  Re: cross section areas
Message-ID:  &lt;9302241112.aa21765@WUMPUS.BRL.MIL&gt;

<p>

<p>
Yes, I got the cross-section in a test I just ran with a 1-inch cube.
At azim 0 & elev 0, I was looking head on at one of the faces (with
another face being flush with the ground), and at that view "area"
gave me 1 square inch.  Then I went to azim 45 & elev 0, and "area"
gave me square-root-of-two (about 1.414) square inches.

<p>
I also don't know what I'd do to pass a different cutting plane through.
The best I could do would be to delete (using "d") objects which project
beyond the area I want to see.

<p>
Another test with the cube was to go back to azim 0 & elev 0 and hollow out
a portion of it so that what's left looked something like:

<p>
*****                 *****
*   *    instead of   *****
*****                 *****

<p>
and I still got 1 square inch.  Notice that the face which is showing
still has all its edges intact.  I then expanded the subtraction so
that part of one of those edges was chopped off:

<p>
*   *
*   *
*****

<p>
and that reduced what "area" gave me.  "area" is obviously ignoring holes
except for holes which cut into the outer edge.
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa18245; 1 Mar 93 17:30 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa17213; 1 Mar 93 16:55 EST
Received: from waffle.brl.mil by WALRUS.BRL.MIL id aa17185; 1 Mar 93 16:45 EST
Date:     Mon, 1 Mar 93 16:43:31 EST
From:     Paul Stay &lt;stay@BRL.MIL&gt;
To:       huston@huston.mdc.com
cc:       CAD@BRL.MIL
Subject:  Re:  Ray tracing of NURBS objects
Message-ID:  &lt;9303011643.aa24667@WAFFLE.BRL.MIL&gt;

<p>
Stu-

<p>
The algorithm which is used by the BRL-CAD software is based on
algorithms found in the SigGraph 1990 paper "Ray Tracing Trimmed rational
Surface Patches" by Nishita, Sederburg, Kamimoto, The routines are
a combination of librt and libnurb. The libnurb routines are included in
the librt library.

<p>
A sample data base can be generated by using the teapot program found in the
proc-db directory.

<p>
Currently the Nurb raytracing routines do not handle trimmed nurbs.
Eventually there will be support for trimmed nurbs as part of the
NMG routines.  At the time of the last BRL-CAD meeting the libnurb
library routines were still in a state of change. I hope to have some
documentation on the libnurb library before the next release.

<p>
-Paul

<p>
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa20193; 8 Mar 93 16:08 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa18544; 8 Mar 93 16:07 EST
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa18364; 8 Mar 93 16:00 EST
Date:     Mon, 8 Mar 93 15:53:51 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  Kodak Photo-CD
Message-ID:  &lt;9303081553.aa19771@WOLF.BRL.MIL&gt;

<p>
On Friday, I was able to test the program "hpcdppm" which I obtained
from the network.  It worked, allowing my Sun-4 workstation to read
images off a Kodak Photo-CD CD-ROM.

<p>
It was short work to mutate that program into "pcd-pix", and that
works too.

<p>
Basically, any machine that can mount a CD-ROM with High Sierra (ISO 9660)
filesystem and retrieve files from there is likely to be able to use
this program.

<p>
This represents a new way that experimental and field data can be digitized
and brought into the computer for analysis.
	Best,
	 -Mike
<hr>
<hr>
Received: from vat.brl.mil by WOLF.BRL.MIL id aa24502; 22 Mar 93 16:24 EST
Date:     Mon, 22 Mar 93 16:15:55 EST
From:     "John R. Anderson" (SLAD/BVLD/ASB) &lt;jra@BRL.MIL&gt;
To:       mike@BRL.MIL, jill@BRL.MIL
cc:       earl@BRL.MIL
Subject:  IGES/PDES Organization (IPO) Meeting
Message-ID:  &lt;9303221615.aa07919@VAT.BRL.MIL&gt;

<p>
	Dr. Walbert has agreed to provide funding for me to TDY to the IPO
meeting in Nashville the week of April 4.  If both of you are agreeable, I would
like to attend.

<p>
	Mike, I haven't had a chance to talk to you about IGES, but there are a few
problems with the standard for a hybrid system with boolean trees (like BRLCAD).
One problem is that the CSG standard has a limited vocabulary of primitive solids,
and in particular cannot handle our TGC, polysolid, or arb8's with non-right angles.
When Earl and I heard about the BREP standard, we thought that these solids could be
handled by making them BREP objects. Unfortunately, when the new standard came out,
the CSG boolean trees were prohibited from containing BREP objects, so we are still
stuck. It seems to us (Earl and me) that the solution is to remove the restriction
on CSG boolean trees and possibly enrich the CSG vocabulary.

<p>
	Another concern is that the same people who developed IGES are developing PDES.
If we don't do something now, we are likely to end up with the same problems on PDES.
This meeting in Nashville is a combined meeting of both the IGES and PDES people and
is a convenient oppurtunity to start pushing those people around to "correct" thinking.

<p>

<p>
				-John

<p>
<hr>
<hr>
Received: from spark.brl.mil by WOLF.BRL.MIL id aa00431; 24 Mar 93 0:35 EST
Date:     Wed, 24 Mar 93 0:34:58 EST
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       acst@BRL.MIL
cc:       jgrosh@BRL.MIL
Subject:  Another Animation Fix
Message-ID:  &lt;9303240034.aa19979@SPARK.BRL.MIL&gt;

<p>
I put the defaulting into MGED where "preview" uses the current
MGED view if none is given in the script.  Lets you preview
animations from any angle, and saves the need to put view specs
in your scripts.

<p>
- Phil
<hr>
<hr>
Received: from sem.brl.mil by WOLF.BRL.MIL id aa07004; 24 Mar 93 9:44 EST
Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa12156; 24 Mar 93 9:41 EST
Received: from tbd2.brl.mil by SEM.BRL.MIL id aa12146; 24 Mar 93 9:40 EST
Date:     Wed, 24 Mar 93 9:34:19 EST
From:     "C. Cindy Sim" &lt;cindys@BRL.MIL&gt;
To:       x11@BRL.MIL
cc:       turek@BRL.MIL
Subject:  NCD rgb.txt
Message-ID:  &lt;9303240934.aa11380@TBD2.BRL.MIL&gt;

<p>
Here is a copy of NCD rgb.txt which contains lots of colors.  Could
you replace this file with one that we currently have for rdist?

<p>
					Cindy

<p>
-------------------------------------------------------

<pre>
255 250 250		snow
248 248 255		ghost white
248 248 255		GhostWhite
245 245 245		white smoke
245 245 245		WhiteSmoke
220 220 220		gainsboro
255 250 240		floral white
255 250 240		FloralWhite
253 245 230		old lace
253 245 230		OldLace
250 240 230		linen
250 235 215		antique white
250 235 215		AntiqueWhite
255 239 213		papaya whip
255 239 213		PapayaWhip
255 235 205		blanched almond
255 235 205		BlanchedAlmond
255 228 196		bisque
255 218 185		peach puff
255 218 185		PeachPuff
255 222 173		navajo white
255 222 173		NavajoWhite
255 228 181		moccasin
255 248 220		cornsilk
255 255 240		ivory
255 250 205		lemon chiffon
255 250 205		LemonChiffon
255 245 238		seashell
240 255 240		honeydew
245 255 250		mint cream
245 255 250		MintCream
240 255 255		azure
240 248 255		alice blue
240 248 255		AliceBlue
230 230 250		lavender
255 240 245		lavender blush
255 240 245		LavenderBlush
255 228 225		misty rose
255 228 225		MistyRose
255 255 255		white
  0   0   0		black
 47  79  79		dark slate gray
 47  79  79		DarkSlateGray
 47  79  79		dark slate grey
 47  79  79		DarkSlateGrey
105 105 105		dim gray
105 105 105		DimGray
105 105 105		dim grey
105 105 105		DimGrey
112 128 144		slate gray
112 128 144		SlateGray
112 128 144		slate grey
112 128 144		SlateGrey
119 136 153		light slate gray
119 136 153		LightSlateGray
119 136 153		light slate grey
119 136 153		LightSlateGrey
192 192 192		gray
192 192 192		grey
211 211 211		light grey
211 211 211		LightGrey
211 211 211		light gray
211 211 211		LightGray
 25  25 112		midnight blue
 25  25 112		MidnightBlue
  0   0 128		navy
  0   0 128		navy blue
  0   0 128		NavyBlue
100 149 237		cornflower blue
100 149 237		CornflowerBlue
 72  61 139		dark slate blue
 72  61 139		DarkSlateBlue
106  90 205		slate blue
106  90 205		SlateBlue
123 104 238		medium slate blue
123 104 238		MediumSlateBlue
132 112 255		light slate blue
132 112 255		LightSlateBlue
  0   0 205		medium blue
  0   0 205		MediumBlue
 65 105 225		royal blue
 65 105 225		RoyalBlue
  0   0 255		blue
 30 144 255		dodger blue
 30 144 255		DodgerBlue
  0 171 232		decwblue
  0 171 232		DECWBlue
  0 191 255		deep sky blue
  0 191 255		DeepSkyBlue
135 206 235		sky blue
135 206 235		SkyBlue
135 206 250		light sky blue
135 206 250		LightSkyBlue
 70 130 180		steel blue
 70 130 180		SteelBlue
176 196 222		light steel blue
176 196 222		LightSteelBlue
173 216 230		light blue
173 216 230		LightBlue
176 224 230		powder blue
176 224 230		PowderBlue
175 238 238		pale turquoise
175 238 238		PaleTurquoise
  0 206 209		dark turquoise
  0 206 209		DarkTurquoise
 72 209 204		medium turquoise
 72 209 204		MediumTurquoise
 64 224 208		turquoise
  0 255 255		cyan
224 255 255		light cyan
224 255 255		LightCyan
 95 158 160		cadet blue
 95 158 160		CadetBlue
102 205 170		medium aquamarine
102 205 170		MediumAquamarine
127 255 212		aquamarine
  0 100   0		dark green
  0 100   0		DarkGreen
 85 107  47		dark olive green
 85 107  47		DarkOliveGreen
143 188 143		dark sea green
143 188 143		DarkSeaGreen
 46 139  87		sea green
 46 139  87		SeaGreen
 60 179 113		medium sea green
 60 179 113		MediumSeaGreen
 32 178 170		light sea green
 32 178 170		LightSeaGreen
152 251 152		pale green
152 251 152		PaleGreen
  0 255 127		spring green
  0 255 127		SpringGreen
124 252   0		lawn green
124 252   0		LawnGreen
  0 255   0		green
127 255   0		chartreuse
  0 250 154		medium spring green
  0 250 154		MediumSpringGreen
173 255  47		green yellow
173 255  47		GreenYellow
 50 205  50		lime green
 50 205  50		LimeGreen
154 205  50		yellow green
154 205  50		YellowGreen
 34 139  34		forest green
 34 139  34		ForestGreen
107 143  36		medium forest green
107 143  36		MediumForestGreen
107 142  35		olive drab
107 142  35		OliveDrab
189 183 107		dark khaki
189 183 107		DarkKhaki
240 230 140		khaki
238 232 170		pale goldenrod
238 232 170		PaleGoldenrod
250 250 210		light goldenrod yellow
250 250 210		LightGoldenrodYellow
255 255 224		light yellow
255 255 224		LightYellow
255 255   0		yellow
255 215   0 		gold
238 221 130		light goldenrod
238 221 130		LightGoldenrod
235 235 173		medium goldenrod
235 235 173		MediumGoldenrod
218 165  32		goldenrod
184 134  11		dark goldenrod
184 134  11		DarkGoldenrod
188 143 143		rosy brown
188 143 143		RosyBrown
205  92  92		indian red
205  92  92		IndianRed
139  69  19		saddle brown
139  69  19		SaddleBrown
160  82  45		sienna
205 133  63		peru
222 184 135		burlywood
245 245 220		beige
245 222 179		wheat
244 164  96		sandy brown
244 164  96		SandyBrown
210 180 140		tan
210 105  30		chocolate
178  34  34		firebrick
165  42  42		brown
233 150 122		dark salmon
233 150 122		DarkSalmon
250 128 114		salmon
255 160 122		light salmon
255 160 122		LightSalmon
255 165   0		orange
255 140   0		dark orange
255 140   0		DarkOrange
255 127  80		coral
240 128 128		light coral
240 128 128		LightCoral
255  99  71		tomato
255  69   0		orange red
255  69   0		OrangeRed
255   0   0		red
255 105 180		hot pink
255 105 180		HotPink
255  20 147		deep pink
255  20 147		DeepPink
255 192 203		pink
255 182 193		light pink
255 182 193		LightPink
219 112 147		pale violet red
219 112 147		PaleVioletRed
176  48  96		maroon
199  21 133		medium violet red
199  21 133		MediumVioletRed
208  32 144		violet red
208  32 144		VioletRed
255   0 255		magenta
238 130 238		violet
221 160 221		plum
218 112 214		orchid
186  85 211		medium orchid
186  85 211		MediumOrchid
153  50 204		dark orchid
153  50 204		DarkOrchid
148   0 211		dark violet
148   0 211		DarkViolet
138  43 226		blue violet
138  43 226		BlueViolet
160  32 240		purple
147 112 219		medium purple
147 112 219		MediumPurple
216 191 216		thistle
255 250 250		snow1
238 233 233		snow2
205 201 201		snow3
139 137 137		snow4
255 245 238		seashell1
238 229 222		seashell2
205 197 191		seashell3
139 134 130		seashell4
255 239 219		AntiqueWhite1
238 223 204		AntiqueWhite2
205 192 176		AntiqueWhite3
139 131 120		AntiqueWhite4
255 228 196		bisque1
238 213 183		bisque2
205 183 158		bisque3
139 125 107		bisque4
255 218 185		PeachPuff1
238 203 173		PeachPuff2
205 175 149		PeachPuff3
139 119 101		PeachPuff4
255 222 173		NavajoWhite1
238 207 161		NavajoWhite2
205 179 139		NavajoWhite3
139 121	 94		NavajoWhite4
255 250 205		LemonChiffon1
238 233 191		LemonChiffon2
205 201 165		LemonChiffon3
139 137 112		LemonChiffon4
255 248 220		cornsilk1
238 232 205		cornsilk2
205 200 177		cornsilk3
139 136 120		cornsilk4
255 255 240		ivory1
238 238 224		ivory2
205 205 193		ivory3
139 139 131		ivory4
240 255 240		honeydew1
224 238 224		honeydew2
193 205 193		honeydew3
131 139 131		honeydew4
255 240 245		LavenderBlush1
238 224 229		LavenderBlush2
205 193 197		LavenderBlush3
139 131 134		LavenderBlush4
255 228 225		MistyRose1
238 213 210		MistyRose2
205 183 181		MistyRose3
139 125 123		MistyRose4
240 255 255		azure1
224 238 238		azure2
193 205 205		azure3
131 139 139		azure4
131 111 255		SlateBlue1
122 103 238		SlateBlue2
105  89 205		SlateBlue3
 71  60 139		SlateBlue4
 72 118 255		RoyalBlue1
 67 110 238		RoyalBlue2
 58  95 205		RoyalBlue3
 39  64 139		RoyalBlue4
  0   0 255		blue1
  0   0 238		blue2
  0   0 205		blue3
  0   0 139		blue4
 30 144 255		DodgerBlue1
 28 134 238		DodgerBlue2
 24 116 205		DodgerBlue3
 16  78 139		DodgerBlue4
 99 184 255		SteelBlue1
 92 172 238		SteelBlue2
 79 148 205		SteelBlue3
 54 100 139		SteelBlue4
  0 191 255		DeepSkyBlue1
  0 178 238		DeepSkyBlue2
  0 154 205		DeepSkyBlue3
  0 104 139		DeepSkyBlue4
135 206 255		SkyBlue1
126 192 238		SkyBlue2
108 166 205		SkyBlue3
 74 112 139		SkyBlue4
176 226 255		LightSkyBlue1
164 211 238		LightSkyBlue2
141 182 205		LightSkyBlue3
 96 123 139		LightSkyBlue4
198 226 255		SlateGray1
185 211 238		SlateGray2
159 182 205		SlateGray3
108 123 139		SlateGray4
202 225 255		LightSteelBlue1
188 210 238		LightSteelBlue2
162 181 205		LightSteelBlue3
110 123 139		LightSteelBlue4
191 239 255		LightBlue1
178 223 238		LightBlue2
154 192 205		LightBlue3
104 131 139		LightBlue4
224 255 255		LightCyan1
209 238 238		LightCyan2
180 205 205		LightCyan3
122 139 139		LightCyan4
187 255 255		PaleTurquoise1
174 238 238		PaleTurquoise2
150 205 205		PaleTurquoise3
102 139 139		PaleTurquoise4
152 245 255		CadetBlue1
142 229 238		CadetBlue2
122 197 205		CadetBlue3
 83 134 139		CadetBlue4
  0 245 255		turquoise1
  0 229 238		turquoise2
  0 197 205		turquoise3
  0 134 139		turquoise4
  0 255 255		cyan1
  0 238 238		cyan2
  0 205 205		cyan3
  0 139 139		cyan4
151 255 255		DarkSlateGray1
141 238 238		DarkSlateGray2
121 205 205		DarkSlateGray3
 82 139 139		DarkSlateGray4
127 255 212		aquamarine1
118 238 198		aquamarine2
102 205 170		aquamarine3
 69 139 116		aquamarine4
193 255 193		DarkSeaGreen1
180 238 180		DarkSeaGreen2
155 205 155		DarkSeaGreen3
105 139 105		DarkSeaGreen4
 84 255 159		SeaGreen1
 78 238 148		SeaGreen2
 67 205 128		SeaGreen3
 46 139	 87		SeaGreen4
154 255 154		PaleGreen1
144 238 144		PaleGreen2
124 205 124		PaleGreen3
 84 139	 84		PaleGreen4
  0 255 127		SpringGreen1
  0 238 118		SpringGreen2
  0 205 102		SpringGreen3
  0 139	 69		SpringGreen4
  0 255	  0		green1
  0 238	  0		green2
  0 205	  0		green3
  0 139	  0		green4
127 255	  0		chartreuse1
118 238	  0		chartreuse2
102 205	  0		chartreuse3
 69 139	  0		chartreuse4
192 255	 62		OliveDrab1
179 238	 58		OliveDrab2
154 205	 50		OliveDrab3
105 139	 34		OliveDrab4
202 255 112		DarkOliveGreen1
188 238 104		DarkOliveGreen2
162 205	 90		DarkOliveGreen3
110 139	 61		DarkOliveGreen4
255 246 143		khaki1
238 230 133		khaki2
205 198 115		khaki3
139 134	 78		khaki4
255 236 139		LightGoldenrod1
238 220 130		LightGoldenrod2
205 190 112		LightGoldenrod3
139 129	 76		LightGoldenrod4
255 255 224		LightYellow1
238 238 209		LightYellow2
205 205 180		LightYellow3
139 139 122		LightYellow4
255 255	  0		yellow1
238 238	  0		yellow2
205 205	  0		yellow3
139 139	  0		yellow4
255 215	  0		gold1
238 201	  0		gold2
205 173	  0		gold3
139 117	  0		gold4
255 193	 37		goldenrod1
238 180	 34		goldenrod2
205 155	 29		goldenrod3
139 105	 20		goldenrod4
255 185	 15		DarkGoldenrod1
238 173	 14		DarkGoldenrod2
205 149	 12		DarkGoldenrod3
139 101	  8		DarkGoldenrod4
255 193 193		RosyBrown1
238 180 180		RosyBrown2
205 155 155		RosyBrown3
139 105 105		RosyBrown4
255 106 106		IndianRed1
238  99	 99		IndianRed2
205  85	 85		IndianRed3
139  58	 58		IndianRed4
255 130	 71		sienna1
238 121	 66		sienna2
205 104	 57		sienna3
139  71	 38		sienna4
255 211 155		burlywood1
238 197 145		burlywood2
205 170 125		burlywood3
139 115	 85		burlywood4
255 231 186		wheat1
238 216 174		wheat2
205 186 150		wheat3
139 126 102		wheat4
255 165	 79		tan1
238 154	 73		tan2
205 133	 63		tan3
139  90	 43		tan4
255 127	 36		chocolate1
238 118	 33		chocolate2
205 102	 29		chocolate3
139  69	 19		chocolate4
255  48	 48		firebrick1
238  44	 44		firebrick2
205  38	 38		firebrick3
139  26	 26		firebrick4
255  64	 64		brown1
238  59	 59		brown2
205  51	 51		brown3
139  35	 35		brown4
255 140 105		salmon1
238 130	 98		salmon2
205 112	 84		salmon3
139  76	 57		salmon4
255 160 122		LightSalmon1
238 149 114		LightSalmon2
205 129	 98		LightSalmon3
139  87	 66		LightSalmon4
255 165	  0		orange1
238 154	  0		orange2
205 133	  0		orange3
139  90	  0		orange4
255 127	  0		DarkOrange1
238 118	  0		DarkOrange2
205 102	  0		DarkOrange3
139  69	  0		DarkOrange4
255 114	 86		coral1
238 106	 80		coral2
205  91	 69		coral3
139  62	 47		coral4
255  99	 71		tomato1
238  92	 66		tomato2
205  79	 57		tomato3
139  54	 38		tomato4
255  69	  0		OrangeRed1
238  64	  0		OrangeRed2
205  55	  0		OrangeRed3
139  37	  0		OrangeRed4
255   0	  0		red1
238   0	  0		red2
205   0	  0		red3
139   0	  0		red4
255  20 147		DeepPink1
238  18 137		DeepPink2
205  16 118		DeepPink3
139  10	 80		DeepPink4
255 110 180		HotPink1
238 106 167		HotPink2
205  96 144		HotPink3
139  58  98		HotPink4
255 181 197		pink1
238 169 184		pink2
205 145 158		pink3
139  99 108		pink4
255 174 185		LightPink1
238 162 173		LightPink2
205 140 149		LightPink3
139  95 101		LightPink4
255 130 171		PaleVioletRed1
238 121 159		PaleVioletRed2
205 104 137		PaleVioletRed3
139  71	 93		PaleVioletRed4
255  52 179		maroon1
238  48 167		maroon2
205  41 144		maroon3
139  28	 98		maroon4
255  62 150		VioletRed1
238  58 140		VioletRed2
205  50 120		VioletRed3
139  34	 82		VioletRed4
255   0 255		magenta1
238   0 238		magenta2
205   0 205		magenta3
139   0 139		magenta4
255 131 250		orchid1
238 122 233		orchid2
205 105 201		orchid3
139  71 137		orchid4
255 187 255		plum1
238 174 238		plum2
205 150 205		plum3
139 102 139		plum4
224 102 255		MediumOrchid1
209  95 238		MediumOrchid2
180  82 205		MediumOrchid3
122  55 139		MediumOrchid4
191  62 255		DarkOrchid1
178  58 238		DarkOrchid2
154  50 205		DarkOrchid3
104  34 139		DarkOrchid4
155  48 255		purple1
145  44 238		purple2
125  38 205		purple3
 85  26 139		purple4
171 130 255		MediumPurple1
159 121 238		MediumPurple2
137 104 205		MediumPurple3
 93  71 139		MediumPurple4
255 225 255		thistle1
238 210 238		thistle2
205 181 205		thistle3
139 123 139		thistle4
  0   0   0		gray0
  0   0   0		grey0
  3   3   3		gray1
  3   3   3		grey1
  5   5   5		gray2
  5   5   5		grey2
  8   8   8		gray3
  8   8   8		grey3
 10  10  10 		gray4
 10  10  10 		grey4
 13  13  13 		gray5
 13  13  13 		grey5
 15  15  15 		gray6
 15  15  15 		grey6
 18  18  18 		gray7
 18  18  18 		grey7
 20  20  20 		gray8
 20  20  20 		grey8
 23  23  23 		gray9
 23  23  23 		grey9
 26  26  26 		gray10
 26  26  26 		grey10
 28  28  28 		gray11
 28  28  28 		grey11
 31  31  31 		gray12
 31  31  31 		grey12
 33  33  33 		gray13
 33  33  33 		grey13
 36  36  36 		gray14
 36  36  36 		grey14
 38  38  38 		gray15
 38  38  38 		grey15
 41  41  41 		gray16
 41  41  41 		grey16
 43  43  43 		gray17
 43  43  43 		grey17
 46  46  46 		gray18
 46  46  46 		grey18
 48  48  48 		gray19
 48  48  48 		grey19
 51  51  51 		gray20
 51  51  51 		grey20
 54  54  54 		gray21
 54  54  54 		grey21
 56  56  56 		gray22
 56  56  56 		grey22
 59  59  59 		gray23
 59  59  59 		grey23
 61  61  61 		gray24
 61  61  61 		grey24
 64  64  64 		gray25
 64  64  64 		grey25
 66  66  66 		gray26
 66  66  66 		grey26
 69  69  69 		gray27
 69  69  69 		grey27
 71  71  71 		gray28
 71  71  71 		grey28
 74  74  74 		gray29
 74  74  74 		grey29
 77  77  77 		gray30
 77  77  77 		grey30
 79  79  79 		gray31
 79  79  79 		grey31
 82  82  82 		gray32
 82  82  82 		grey32
 84  84  84 		gray33
 84  84  84 		grey33
 87  87  87 		gray34
 87  87  87 		grey34
 89  89  89 		gray35
 89  89  89 		grey35
 92  92  92 		gray36
 92  92  92 		grey36
 94  94  94 		gray37
 94  94  94 		grey37
 97  97  97 		gray38
 97  97  97 		grey38
 99  99  99 		gray39
 99  99  99 		grey39
102 102 102 		gray40
102 102 102 		grey40
105 105 105 		gray41
105 105 105 		grey41
107 107 107 		gray42
107 107 107 		grey42
110 110 110 		gray43
110 110 110 		grey43
112 112 112 		gray44
112 112 112 		grey44
115 115 115 		gray45
115 115 115 		grey45
117 117 117 		gray46
117 117 117 		grey46
120 120 120 		gray47
120 120 120 		grey47
122 122 122 		gray48
122 122 122 		grey48
125 125 125 		gray49
125 125 125 		grey49
127 127 127 		gray50
127 127 127 		grey50
130 130 130 		gray51
130 130 130 		grey51
133 133 133 		gray52
133 133 133 		grey52
135 135 135 		gray53
135 135 135 		grey53
138 138 138 		gray54
138 138 138 		grey54
140 140 140 		gray55
140 140 140 		grey55
143 143 143 		gray56
143 143 143 		grey56
145 145 145 		gray57
145 145 145 		grey57
148 148 148 		gray58
148 148 148 		grey58
150 150 150 		gray59
150 150 150 		grey59
153 153 153 		gray60
153 153 153 		grey60
156 156 156 		gray61
156 156 156 		grey61
158 158 158 		gray62
158 158 158 		grey62
161 161 161 		gray63
161 161 161 		grey63
163 163 163 		gray64
163 163 163 		grey64
166 166 166 		gray65
166 166 166 		grey65
168 168 168 		gray66
168 168 168 		grey66
171 171 171 		gray67
171 171 171 		grey67
173 173 173 		gray68
173 173 173 		grey68
176 176 176 		gray69
176 176 176 		grey69
179 179 179 		gray70
179 179 179 		grey70
181 181 181 		gray71
181 181 181 		grey71
184 184 184 		gray72
184 184 184 		grey72
186 186 186 		gray73
186 186 186 		grey73
189 189 189 		gray74
189 189 189 		grey74
191 191 191 		gray75
191 191 191 		grey75
194 194 194 		gray76
194 194 194 		grey76
196 196 196 		gray77
196 196 196 		grey77
199 199 199 		gray78
199 199 199 		grey78
201 201 201 		gray79
201 201 201 		grey79
204 204 204 		gray80
204 204 204 		grey80
207 207 207 		gray81
207 207 207 		grey81
209 209 209 		gray82
209 209 209 		grey82
212 212 212 		gray83
212 212 212 		grey83
214 214 214 		gray84
214 214 214 		grey84
217 217 217 		gray85
217 217 217 		grey85
219 219 219 		gray86
219 219 219 		grey86
222 222 222 		gray87
222 222 222 		grey87
224 224 224 		gray88
224 224 224 		grey88
227 227 227 		gray89
227 227 227 		grey89
229 229 229 		gray90
229 229 229 		grey90
232 232 232 		gray91
232 232 232 		grey91
235 235 235 		gray92
235 235 235 		grey92
237 237 237 		gray93
237 237 237 		grey93
240 240 240 		gray94
240 240 240 		grey94
242 242 242 		gray95
242 242 242 		grey95
245 245 245 		gray96
245 245 245 		grey96
247 247 247 		gray97
247 247 247 		grey97
250 250 250 		gray98
250 250 250 		grey98
252 252 252 		gray99
252 252 252 		grey99
255 255 255 		gray100
255 255 255 		grey100
</pre>
<hr>
Received: from spark.brl.mil by WOLF.BRL.MIL id aa00247; 6 Apr 93 0:43 EDT
Date:     Tue, 6 Apr 93 0:43:12 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       acst@BRL.MIL
cc:       jgrosh@BRL.MIL
Subject:  Another animimation bug - fixed
Message-ID:  &lt;9304060043.aa24911@SPARK.BRL.MIL&gt;

<p>
John found another bug today: If you change the view parameters
from frame to frame, RT gives the wrong results (i.e. the wrong
view), while MGED was correct.

<p>
What was happening was that since you can either set the width/height
(via -n -w; or set width=xxx) or the cell_width/cell_height (via
-g -G; or; opt -g -G), RT was checking for a zero value in one of
these pairs (to see which the user set), and computing the OTHER
pair based on the ones given.  If neither was zero, it did nothing
(assuming it has already been computed - which it was).  However,
in an animation, if you change the viewsize, or any of the above named
parameters, these values need to be recomputed.  This wasn't happening.

<p>
I added a cell_newsize flag to indicate when a new -g or -G was given,
and then ALWAYS do the grid computation code, choosing the version based
on cell_newsize.  Changes are checked into rt/ext.h, opt.c, worker.c.

<p>
- Phil
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa23994; 5 Apr 93 16:49 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa28607; 5 Apr 93 16:45 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa28590; 5 Apr 93 16:43 EDT
Received: from fidler.chinalake.navy.mil by WHARF.BRL.MIL id aa00762;
          5 Apr 93 16:37 EDT
Received: by fidler.chinalake.navy.mil (MX V3.2) id 228; Mon, 05 Apr 1993
          13:38:20 PDT
Date: Mon, 05 Apr 1993 13:38:18 PDT
From: levine@fidler.chinalake.navy.mil
To: cad@BRL.MIL
Message-ID: &lt;0096A940.084C0800.228@fidler.chinalake.navy.mil&gt;
Subject: BRL-CAD 4.1 MGED screen is BLACK ...

<p>
	I have just installed BRL-CAD 4.1 on an SGI SKYWRITER
(two graphics heads) running 4.0.5(A). The software was built to run
in /data3/brlcad.....
 When I run MGED, useing one of the sample databases, the MGED
window comes up, but no buttons show up on the left had side of the
screen. When I issue the B command to draw the database, the figure
flashes on the screen for about 1 scan then the contents of the window
goes black. The same for left/center/right button -  the figure
appears for about 1 scan and then the window contents goes to black
again.
	Any suggestions as to the cause/cure???

<p>
Michael N. LeVine  Naval Air Weapons Station, China Lake, Ca 93555, USA
Internet: levine@fidler.chinalake.navy.mil
(619) 939-2614  avn  437-2614

<p>
 "Waiter, there's a bug in my soup!"
 "No, Sir, it's not a bug, it's a feature!"

<p>
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa07525; 6 Apr 93 14:30 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa11852; 6 Apr 93 14:26 EDT
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa11730; 6 Apr 93 14:16 EDT
Date:     Tue, 6 Apr 93 14:12:15 EDT
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
To:       levine@fidler.chinalake.navy.mil
cc:       cad@BRL.MIL
Subject:  Re:  BRL-CAD 4.1 MGED screen is BLACK ...
Message-ID:  &lt;9304061412.aa07139@WOLF.BRL.MIL&gt;

<p>
&gt; I have just installed BRL-CAD 4.1 on an SGI SKYWRITER
...
&gt; When I issue the B command to draw the database, the figure
&gt;flashes on the screen for about 1 scan then the contents of the window
&gt;goes black. The same for left/center/right button -  the figure
&gt;appears for about 1 scan and then the window contents goes to black
&gt;again.
&gt;	Any suggestions as to the cause/cure???

<p>
The place to look is in "mged/dm-4d.c".  The problem may have to do with the
SKYWRITER's implementation of double/single buffered modes.  Since I don't
have one of these displays, I'm afraid I can't help much more than that.

<p>
Lee A. Butler
Attn: AMSRL-SL-BV
U.S. Army Research Laboratory			Internet: butler@brl.mil
Aberdeen Proving Ground, MD  21005-5068		Phone: (410) 278-9200

<p>
<hr>
<hr>
Received: from vim.brl.mil by WOLF.BRL.MIL id aa19523; 7 Apr 93 8:18 EDT
Received: from worm.brl.mil by VIM.BRL.MIL id aa28723; 7 Apr 93 8:13 EDT
Date:     Wed, 7 Apr 93 8:05:59 EDT
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.MIL&gt;
To:       bvld@BRL.MIL
Subject:  [Gary S. Moss:  Re: xpa utility]
Message-ID:  &lt;9304070805.aa03491@WORM.BRL.MIL&gt;

<p>
I thought that I had announced the availability of "xpa", but perhaps
I never got around to it.

<p>
	This is an official warning that the products and moments of
	inertia calculation has not undergone extensive validation.
	If someone has an alternative means for checking the numbers
	for some fairly complicated geometries, I would appreciate
	if they would report their findings back to me. I did check it
	against simple test cases for which the answer could be easily
	computed by hand.

<p>

<p>
----- Forwarded message # 1:

<p>
Date:     Wed, 7 Apr 93 7:46:23 EDT
From:     Gary S. Moss (VLD/VMB)  &lt;moss@BRL&gt;
To:       Carl Moore &lt;cmoore@brl.mil&gt;
cc:       moss@BRL.MIL
Subject:  Re:  xpa utility
Message-ID:  &lt;9304070746.aa03396@WORM.BRL.MIL&gt;

<p>

<p>
# I am hearing of an "xpa" utility which can be used for cross-section area,
# etc., from someone in the former TBD.  Is there any documentation around for
# it, as I had not heard of it before.

<p>
Carl,
	Xpa computes presented area, not cross-sectional area.  It also
computes volume, mass, centroids, moments and products of inertia.

<p>
        Assuming you have /usr/X11/man in your MANPATH, you should be able
to type "man xpa" to get the documentation on it.  It is installed on the
SGIs and Suns that have the X11 and vld software rdist distributions.

<p>
-Gary

<p>

<p>
----- End of forwarded messages
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa21544; 7 Apr 93 12:17 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa29133; 7 Apr 93 11:48 EDT
Received: from vim.brl.mil by WALRUS.BRL.MIL id aa29039; 7 Apr 93 11:39 EDT
Date:     Wed, 7 Apr 93 11:39:41 EDT
From:     Ferd Brundick (BVLD/GSB) &lt;fsbrn@BRL.MIL&gt;
To:       cad@BRL.MIL
Subject:  Sun X11 problems
Message-ID:  &lt;9304071139.aa01750@VIM.BRL.MIL&gt;

<p>
Haah,

<p>
I'm running BRLCAD on an SGI with remote output to a color Sun running
X11R4.  MGED runs ok (except for some ugly color choices) and the
fb commands I tried (rle-fb and cell-fb) run correctly.  I manually
started fbserv on the Sun like this:

<p>
vacation&gt; fbserv -S 1024 0 /dev/X

<p>
with these variables set on the SGI:

<p>
DISPLAY=vacation.brl.mil:0.0
FB_FILE=vacation.brl.mil:0

<p>
Running rle-fb on an existing RLE file displays the proper image (I'm
using cell-fb output and the spectrum at the bottom looks correct).
The framebuffer window is using a private colormap.  However, if I run
fb-rle the new RLE file is always grayscale.  I ran rlehdr on the
original and new files and got identical results, altho the new files
are about one half the size of the originals.  I played around with
the '-c' option and it didn't make any visual difference.

<p>
The problem with rt is more serious.  If I run rt from within MGED or
directly from the command line it *seems* to work but I never get an
image in the framebuffer.

<p>
I grep'd on X11 in the BRLCAD man tree and only 4 files even metioned
X11 -- mged (reminding people to define DISPLAY), pl-X (display
UnixPlot in an X11 window), urt (getx11 program), and libfb (use -lX11
when linking X programs).  There's nothing about defining FB_FILE to
point to an X11 client, nor is there an fbserv man page.

<p>
Now that SGI has switched to X11, is there going to be a greater
emphasis on X11 support in BRLCAD?  People have been writing to this
list saying they can run BRLCAD on their Suns under OpenWindows and
other X-ish things, but distributed SGI-&gt;Sun support is weak.

<p>
                                        dsw, fferd
                                        &lt;fsbrn@brl.mil&gt;
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa23426; 7 Apr 93 15:38 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa01589; 7 Apr 93 15:20 EDT
Received: from spark.brl.mil by WALRUS.BRL.MIL id aa01540; 7 Apr 93 15:14 EDT
Date:     Wed, 7 Apr 93 15:17:12 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       Ferd Brundick &lt;fsbrn@BRL.MIL&gt;
cc:       cad@BRL.MIL
Subject:  Re:  Sun X11 problems
Message-ID:  &lt;9304071517.aa07104@SPARK.BRL.MIL&gt;

<p>
Ferd,

<p>
Remember "fbhelp", it will show you frame buffer options.
Try /dev/Xm.  The "m" means that it allocates a 24-bit memory buffer
to hold the image info, even if the display has e.g. only 1-bit.
This way pixel readback (such as fb-pix) will get the right values,
otherwise the best you can do is read the scant bitplanes from the
X server.  [You might have found a real bug, but this may work around
it.]

<p>
The other way to get 24-bit readback is to use /dev/mem.  On the SGI,
you could do:

<p>
fbserv -S1024 0 "/dev/mem vacation:0" &
FB_FILE=0

<p>
[possibly with 'r' (pre-read), and/or 'w' (write-through) option on /dev/mem]
What this will do is to make a pseudo 24-bit frame buffer on the SGI in
memory, do all libfb operations there, and when an application exits (or
closes the frame buffer) the image will be flushed to any attached frame
buffers (in this case vacation:0).   Doing this also means that readbacks
will be far faster, since they now come from your SGI memory, rather than
the Sun.

<p>
Yes, fbserv, /dev/mem, /dev/X, mged dm-X, aren't well documented.  Point
noted.  I have a small tutorial somewhere on using fbserv.  I'll see if
I can find it and send it to the list.

<p>
About X support in MGED, little known features: In the drawing window,
certain keystrokes do things for you.
  0        zero "knobs" (translates and rotates)
  x, y, z  translate
  X, Y, Z  rotate
  f, t, b, l, r, R, 3, 4  preset-views (front, top, ...)

<p>
| Now that SGI has switched to X11, is there going to be a greater
| emphasis on X11 support in BRLCAD?

<p>
On an SGI, GL still beats the pants off of X as the prefered way to
do graphics.  However, to do GUI's, X is the thing to do.  There is
a much much better MGED X driver in the works (which will also drive
GL windows).  Expect to see it this Summer.

<p>
- Phil
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa16522; 5 Apr 93 3:42 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa17654; 5 Apr 93 3:13 EDT
Received: from spark.brl.mil by WALRUS.BRL.MIL id aa17619; 5 Apr 93 3:04 EDT
Date:     Mon, 5 Apr 93 3:00:12 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       Patrick Haggard &lt;ph@physiol.ox.ac.uk&gt;
cc:       cad@BRL.MIL
Subject:  Combinations, Groups, and Regions
Message-ID:  &lt;9304050300.aa01682@SPARK.BRL.MIL&gt;

<p>
             Combinations, Groups, and Regions

<p>
New users of MGED are often confused over the differences and
relationships between "combinations", "regions", and "groups".
The latter two are special cases of a combination.  A lot of
the confusion in the documentation results from the history by
which we got to the present system.  Here is a "modern" way of
looking at the three(*).

<p>
The fundamental command for building combinations of objects is:

<p>
	comb name &lt;op1 member1&gt; [&lt;op2 member2&gt; ...]

<p>
Where the members are either other combinations or primitives (single
solids).  The first &lt;op&gt; is meaningless.  Many people use union (u),
but some argue that intersect (+) should be used. [To distinguish this
from a group perhaps??  I've never understood their reasoning.]

<p>
If all of the operations are unions, there is a shorthand version of the
above to make what is called a "group" (a combination of all unions):

<p>
	g name &lt;member1&gt; [&lt;member2&gt; ...]

<p>
The result of this command is *exactly* the same as having made a
combination (comb) with all union (u) operations.  I.e.

<p>
	comb name &lt;u member1&gt; &lt;u member2&gt; ...

<p>
Finally, any combination can have a "bit" set (i.e. have a property
of any combination enabled) that makes that combination what is known
as a "region".  The idea of a region is that it consists of one solid
piece of material.  That is, however it was constructed in the editor,
by combining any number of levels of primitive solids and combinations
together, this finally result is one identifiable piece (e.g. a machined
part perhaps).  A combination so identified as a region can have various
properties associated with it: its color, the type of material it is
made out of, a "region id", etc.  There is a special form of the
combination (comb) command that makes a combination with this region
property set:

<p>
	r name &lt;op1 member1&gt; [&lt;op2 member2&gt; ...]

<p>
An existing region or combination (where "combination" is used here
to refer to a non-region, even though technically a region is still
a combination) can have this "bit" turned on or off via:

<p>
	edcomb name regionflag [regionid air los GIFTmater]

<p>
Other ways of editing regions include:

<p>
	item name item# [air]		to change the region_id
and
	mater name [material]		to change the material

<p>
[regdef item [air] [los] [GIFTmaterial] - sets defaults for next "r" cmd]

<p>
Speaking of historical confusion, note that the following names all
refer to the SAME single value!:

<p>
  "region id", "region ident", "ident", "ident code", "item number", "item".

<p>
<hr>
(*) Why I call it modern, is that for quite some time only the "r"
    and "g" commands existed.  "comb" was added much later, yet in
    this authors opinion, is the most fundamental of the three.  You
    used to be able to be fast-and-loose about having regions that
    contain regions, so everything could be built with "r".  When
    the ray tracer became more precise about not allowing two physical
    pieces of material to occupy the same space (overlapping regions),
    it became important to have combination nodes that did NOT have
    the region property turned on, and could thus be freely used as
    members in other combinations.
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa06675; 8 Apr 93 15:57 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa19474; 8 Apr 93 15:54 EDT
Received: from spark.brl.mil by WALRUS.BRL.MIL id aa19414; 8 Apr 93 15:52 EDT
Date:     Thu, 8 Apr 93 15:46:08 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       cad@BRL.MIL
Subject:  History of "comb"
Message-ID:  &lt;9304081546.aa06338@SPARK.BRL.MIL&gt;

<p>
In my note about Combinations, Groups, and Regions, I had said in
the footnote:

<p>
| You used to be able to be fast-and-loose about having regions that
| contain regions, so everything could be built with "r".  When
| the ray tracer became more precise about not allowing two physical
| pieces of material to occupy the same space (overlapping regions),
| it became important to have combination nodes that did NOT have
| the region property turned on, and could thus be freely used as
| members in other combinations.

<p>
Mike Muuss corrected me here.  I remembered "comb" being added, in
part when I complained "If you can't have regions within regions,
how are you supposed to make a non-region combination?"  My reasons
for why it didn't used to be there were wrong however.  Here is a
better footnote:

<p>
(*) Why I call it modern, is that for quite some time only the "r" and
    "g" commands existed.  "comb" was added much later, yet in this
    author's opinion, is the most fundamental of the three.  VDECK and
    GIFT (the predecessor to RT) did not support things such as regions
    within regions, booleans above regions, and non-unions below regions.
    Therefore MGED did not have support for them.  Adding "comb" to MGED
    generalized and increased MGED's expressive power, but it also allowed
    a diversion from GIFT compatible databases.
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa00791; 14 Apr 93 19:36 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa16853; 14 Apr 93 16:27 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa16663; 14 Apr 93 16:16 EDT
Received: from mbv.mbvlab.wpafb.af.mil by WHARF.BRL.MIL id aa06116;
          14 Apr 93 16:09 EDT
Received: from nextclient3.mbvlab.wpafb.af.mil ([134.131.208.19]) by mbv.mbvlab.wpafb.af.mil (4.1/SMI-4.1)
	id AA06792; Wed, 14 Apr 93 16:09:51 EDT
Received: by nextclient3.mbvlab.wpafb.af.mil (NX5.67c/NX3.0S)
	id AA00756; Wed, 14 Apr 93 16:01:21 -0400
Date: Wed, 14 Apr 93 16:01:21 -0400
From: Kevin Farrar (Sverdrup) &lt;kfarrar@nextclient3.mbvlab.wpafb.af.mil&gt;
Message-Id: &lt;9304142001.AA00756@nextclient3.mbvlab.wpafb.af.mil&gt;
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: CAD@BRL.MIL
Subject: Problem with mouse & mged
Cc: pjoslin@mbvlab.wpafb.af.mil, kfarrar@mbvlab.wpafb.af.mil

<p>
I am having a problem with the mouse in mged installed on an
HP9000 Model 750 HP-UX 8.05 attached to X.  I must hit return
at the mged&gt; in the command window to get it to accept my
mouse clicks.

<p>
Kevin Farrar		E-mail:	kfarrar@mbvlab.wpafb.af.mil
Sverdrup Technology	Voice:	(513)255-1115
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa14380; 16 Apr 93 4:38 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa21276; 16 Apr 93 4:04 EDT
Received: from spark.brl.mil by WALRUS.BRL.MIL id aa21021; 16 Apr 93 3:56 EDT
Date:     Fri, 16 Apr 93 3:57:26 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       Kevin Farrar &lt;kfarrar@nextclient3.mbvlab.wpafb.af.mil&gt;
cc:       CAD@BRL.MIL, pjoslin@mbvlab.wpafb.af.mil,
          kfarrar@mbvlab.wpafb.af.mil
Subject:  Re:  Problem with mouse & mged
Message-ID:  &lt;9304160357.aa23871@SPARK.BRL.MIL&gt;

<p>
Chances are that select() is not working correctly.  Look in
"libsysv/bsdselect.c".  If you are falling into the generic
System V code that does a "return(32-1)", you will see the
problem you described.  You need to see if your HP supports a
real select system call and enable it by changing the ifdef's
in that module.

<p>
- Phil
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa22499; 26 Apr 93 14:21 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa06700; 26 Apr 93 9:15 EDT
Date:     Mon, 26 Apr 93 9:05:02 EDT
From:     Susan Coates (BVLD) &lt;scoates@BRL.MIL&gt;
To:       jwb@swrinde.nde.swri.edu
cc:       cad@BRL.MIL, scoates@BRL.MIL
Subject:  Big E Command
Message-ID:  &lt;9304260905.aa06261@WALRUS.BRL.MIL&gt;

<p>

<p>

<p>

<p>

<p>
As far as I know you are not missing anything with reguards to mged.
The 'big e' command has never worked (to the best of my knowledge) on
a torus (or an ars).  The error below is the normal reaction to 'big
eing' a torus (or an ars).  I don't know anything about the same error
with rt.  My experience with tori and rt is that everything seems to
work.

<p>
                                               Susan Coates

<p>

<p>

<p>

<p>

<p>
----- Forwarded message # 1:

<p>
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa21299; 22 Apr 93 10:18 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa21076; 22 Apr 93 10:10 EDT
Received: from swrinde.nde.swri.edu by WHARF.BRL.MIL id aa25089;
          22 Apr 93 10:04 EDT
Received: by swrinde.nde.swri.edu (5.64swri/1.34)
	id AA15798; Thu, 22 Apr 93 09:03:53 -0500
From: "Joseph W. Brophy" &lt;jwb@swrinde.nde.swri.edu&gt;
Message-Id: &lt;9304221403.AA15798@swrinde.nde.swri.edu&gt;
Subject: Error messages from MGED
To: cad@BRL.MIL
Date: Thu, 22 Apr 1993 09:03:53 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL3]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Length: 720

<p>
Forwarded message:
We have run into the following error situation with MGED, attempts to
use torus in combination with other primitives gives the folowing error
with 'Big E' (and RT as well)
&gt; mged&gt; E test04
&gt;
&gt; proc_reg:  Cannot draw solid type 16 (TOR)
&gt; Error in converting solid test04 to ARBN
&gt; E: 0 vectors in 0 sec
&gt;
&gt;
&gt; mged&gt; tree test04
&gt;
&gt;
&gt; test04/R
&gt;         u torus2
&gt;         + cyl3
&gt;
&gt; The problem is the inability to edit the "tor" solid or
&gt; a solid to be edited by a "tor" and disply the results
&gt; with "E"
&gt;
&gt; -tony
&gt;
Is there a patch for MGED, or are we missing something fundamental about
MGED's operation?

<p>
We are using a Sun Sparc workstation with XGL and SunOS 4.1.3.

<p>
JWBrophy@swrinde

<p>

<p>
----- End of forwarded messages
<hr>
<hr>
Date:     Wed, 2 Jun 93 9:27:07 EDT
From:     John R. Anderson (VMB)  &lt;jra@BRL&gt;
To:       mike@BRL.MIL
cc:       jill@BRL.MIL, acst@BRL.MIL
Subject:  BRLCAD to IGES translator
Message-ID:  &lt;9306020927.aa23838@WOLF.BRL.MIL&gt;

<p>
	I have completed the coding of a BRLCAD-to-IGES translator (g-iges).
The code has two mutually exclusive options (plus a few others):

<p>
		-f for facets (each region is converted to NMG's prior to
			output in IGES format).

<p>
		-c for CSG (each object is output in IGES format unless
			there is no corresponding IGES entity, in which case
			it is converted to NMG's and then output).

<p>
	The -f option is essentially Markowski's g-jack converter with
different output and some additions. This option is dependent on the
successful implementation of NMG booleans. One major issue with this
option is that IGES expects BREP objects to consist of one or more outer
shells with zero or more inner void shells, while BRLCAD combines all of
this into a single shell.  This issue is being shelved until we know
for sure whether BRLCAD will use the IGES version of shells.

<p>
	The -c option has been exercised on two real models - the MH60
and MH47 helicopters. The 3.8 Mb mh47.g file produces a 39 Mb, 484,000
line IGES file with all the ARS solids, 65% of the ARB's and 10% of the
TGC's converted to NMG's. Everything else is written to the IGES file
without conversion.  The 4.5 Mb mh60k.g file produced a 59 Mb, 735,000
line IGES file with similar statistics.  There are a few issues here:

<p>
	1. What to do with solids that are not in IGES and are not
	   tessellated (like the half-space solid).

<p>
	2. IGES cannot handle an object that is scaled. If a scaled object
	   that has not been "pushed" is encountered, it is translated to
	   IGES without the scale factor and the user is warned.

<p>
	3. I have not implemented the IGES right angle wedge (RAW) solid.
	   This is just a matter of whether it's worth the effort of
	   developing code to recognize if a BRLCAD arb meets the criteria
	   to be an IGES RAW.

<p>
	Issue #1 was not encountered in either of the two models converted.
Issue #2 was encountered in one region and safely handled by a "push"
command in MGED and then re-running g-iges.

<p>
	Both options produce an IGES file that includes object names
(using the IGES "name" entity), colors (using the IGES color entity),
and region flag, region id, air code, GIFT material code, los, material
name, and material parameters are included using the IGES attribute
entities.  The attribute entity sort of a free for all entity to assign
any attributes to any IGES object.  No other IGES translator will understand
my attribute entity unless they code my conventions into their translator.

<p>
	Obviously, the only verification I have done on this is visual
inspection of the output files.  Given the size of the files, the possibility
of overlooking a bug is not insignificant.  I propose upgrading the existing
iges-g translator to the same level as the new g-iges and using them to
help debug each other.  This would also give me a chance to become familiar
with the nmg "make" routines.

<p>

<p>

<p>
				-John

<p>

<p>
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa07350; 9 Jun 93 12:51 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa08523; 9 Jun 93 12:45 EDT
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa08440; 9 Jun 93 12:39 EDT
Date:     Wed, 9 Jun 93 12:38:14 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  vdeck on RS4000 Indigo
Message-ID:  &lt;9306091238.aa07164@WOLF.BRL.MIL&gt;

<p>
For those of you fans of VDECK, it was reported today that VDECK will
not compile on an SGI R4000 Indigo machine.  In the Release 4.1 sources
this can be worked around by removing line 162, which states:

<p>
int sortFunc RT_ARGS((const void * a, const void *b));

<p>
In the Release 4.0 sources (which probably won't work on an Indigo
anyway), remove line 137, which states:

<p>
static int sortFunc RT_ARGS((const void *a, const void *b));

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa10006; 25 Jun 93 10:27 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa02314; 25 Jun 93 9:47 EDT
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa02222; 25 Jun 93 9:41 EDT
Date:     Fri, 25 Jun 93 9:31:58 EDT
From:     "John R. Anderson" &lt;jra@BRL.MIL&gt;
To:       ali@archsci.arch.su.edu.au
cc:       cad@BRL.MIL
Subject:  Re:  please add me to the mailing list
Message-ID:  &lt;9306250931.aa09301@WOLF.BRL.MIL&gt;

<p>
Ali writes:

<p>
&gt; 	Also, I am trying to get BRL-CAD to work on a Sun
&gt; Sparcstation with SunOS 4.1.2 (and 4.1.3), under OpenWindows (not
&gt; SunView).  I was wondering if anybody else had done this...
&gt;

<p>

<p>
	I have compiled BRLCAD under OpenWindows some time ago. As I recall,
the only changes I had to make were in the "Cakefile.defs" file.
There is a section in that file for Sparcstations (look for
"#if defined(sparc)"). The default is labelled with a comment:
/*              Bare Sun configuration */
You can switch to the OpenWindows support by changing the "if 1" for
the bare sun configuration to an "if 0".  This will enable the section
labelled:
/*              Sun with X11 (aka "openwin").  Default for SunOS 4.1.1 */

<p>

<p>
		Hope this helps,

<p>
		-John

<p>

<p>
John R. Anderson
Attn: AMSRL-SL-BV
U.S. Army Research Laboratory			Internet: jra@brl.mil
Aberdeen Proving Ground, MD  21005-5068		Phone: (410) 278-7267
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa13741; 25 Jun 93 16:37 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa13658; 25 Jun 93 16:33 EDT
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa13597; 25 Jun 93 16:27 EDT
Date:     Fri, 25 Jun 93 16:18:49 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       Patrick Haggard &lt;ph@physiol.ox.ac.uk&gt;
cc:       ali@archsci.arch.su.edu.au, jra@BRL.MIL, cad@BRL.MIL
Subject:  Sun configurations
Message-ID:  &lt;9306251618.aa13546@WOLF.BRL.MIL&gt;

<p>

<p>
You know, you *are* allowed to edit the Cakefile.defs entries, if they
don't suit your particular configuration.  I've tried to provide a
variety of useful selections via the #if mechanism, but once you have
the baseline package working, if you want to make modifications, do feel
free to do so!  One of the benefits (and responsibilities) of getting
software in source code form.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa22308; 29 Jun 93 2:01 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa29328; 29 Jun 93 1:34 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa29274; 29 Jun 93 1:25 EDT
Received: from archsci.arch.su.EDU.AU by WHARF.BRL.MIL id aa00020;
          29 Jun 93 1:14 EDT
Received: from whitton.arch.su.EDU.AU by archsci.arch.su.EDU.AU (5.61+/5.17)
	id AA07084; Tue, 29 Jun 1993 15:13:20 +1000
Received: from [127.0.0.1] by whitton.arch.su.EDU.AU (5.61+/SMI-4.1)
	id AA22133; Tue, 29 Jun 1993 15:13:18 +1000
Message-Id: &lt;9306290513.AA22133@whitton.arch.su.EDU.AU&gt;
To: cad@BRL.MIL
Subject: multi-user MGED
Date: Tue, 29 Jun 93 15:13:17 +1000
From: ali@archsci.arch.su.edu.au

<p>
Hi,
	I'm interested in adding concurrent multi-user capability
to MGED.  I wanted to know if anybody had tried this, or if
anybody had any tips on how I might go about it.  I'm
somewhat familiar with designing multi-user programs, but I am not
familiar with mged yet.  Any suggestions, warnings, etc would be
greatly appreciated...

<p>
thanks,

<p>
-=&gt; Ali
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa22520; 29 Jun 93 3:01 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa00014; 29 Jun 93 2:45 EDT
Received: from spark.brl.mil by WALRUS.BRL.MIL id aa29949; 29 Jun 93 2:38 EDT
Date:     Tue, 29 Jun 93 2:33:58 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       ali@archsci.arch.su.edu.au
cc:       cad@BRL.MIL
Subject:  Re:  multi-user MGED
Message-ID:  &lt;9306290233.aa08483@SPARK.BRL.MIL&gt;

<p>
The new MGED user interface allows multiple X servers to be used
to display geometry.  The alternate displays are even mouse input
sensitive.  We have discussed the issue of whether or not to allow
complete editing capability from every display, and issues such as
whether or not to warp the mouse on one display as it is moved on
another.

<p>
I personally don't see much utility in making it multi-user beyond
seeing the output on multiple desktops and being able to interactively
point out objects/actions to others.  But I'm open to ideas.  How
would you use a multi-user geometric editor?  In something other
than a demonstration/teaching mode?  How would you handle control,
e.g. would all mouse clicks and key presses apply to every display
in a first-come/first-serve fashion?

<p>
- Phil
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa22573; 29 Jun 93 3:14 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa00325; 29 Jun 93 3:15 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa00245; 29 Jun 93 3:07 EDT
Received: from archsci.arch.su.EDU.AU by WHARF.BRL.MIL id aa01065;
          29 Jun 93 3:00 EDT
Received: from whitton.arch.su.EDU.AU by archsci.arch.su.EDU.AU (5.61+/5.17)
	id AA07800; Tue, 29 Jun 1993 16:59:51 +1000
Received: from [127.0.0.1] by whitton.arch.su.EDU.AU (5.61+/SMI-4.1)
	id AA22252; Tue, 29 Jun 1993 16:59:48 +1000
Message-Id: &lt;9306290659.AA22252@whitton.arch.su.EDU.AU&gt;
To: Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject: Re: multi-user MGED
Cc: cad@BRL.MIL
In-Reply-To: Your message of Tue, 29 Jun 93 02:33:58 -0400.
             &lt;9306290233.aa08483@SPARK.BRL.MIL&gt;
Date: Tue, 29 Jun 93 16:59:46 +1000
From: ali@archsci.arch.su.edu.au

<p>
Phil,

<p>
&gt; The new MGED user interface allows multiple X servers to be used
&gt; to display geometry.  The alternate displays are even mouse input
&gt; sensitive.  We have discussed the issue of whether or not to allow
&gt; complete editing capability from every display, and issues such as
&gt; whether or not to warp the mouse on one display as it is moved on
&gt; another.

<p>
where could I get this new MGED UI?  Sounds *very* much like what I'd
want...

<p>
&gt; I personally don't see much utility in making it multi-user beyond
&gt; seeing the output on multiple desktops and being able to interactively
&gt; point out objects/actions to others.  But I'm open to ideas.  How
&gt; would you use a multi-user geometric editor?  In something other
&gt; than a demonstration/teaching mode?  How would you handle control,
&gt; e.g. would all mouse clicks and key presses apply to every display
&gt; in a first-come/first-serve fashion?

<p>
well, that question has many long answers.  The basic idea is
collaborative design.  That's my current area of research.  There is
alot of work being done in collaborative/multi-user programs, and
there are several ways in which you can handle control.  One solution
is to do it the way it would be done in a meeting with a whiteboard.
have one "pen" and allow only one person to edit at a time.  Another
way, (which, in my opinion is the way it should be done) is to allow
people to have their own views of the 3D database, and allow them all
to edit at the same time, but allow for "selection" of objects, and
when somebody has something selected, nobody else can modify it.  It
would also be good to have a local instance running as well, which
would allow users to work on a small part of the design outside of
the main database, and then add it in when they want to show it to
people.  Of course, it would be very important for the designers to
also be speaking to eachother to prevent problems.  A masters student
at MIT named Li Shu did a good piece of work on collaborative cad and
had a paper in CSCW'92...

<p>
hope that answers part of your question...

<p>
-=&gt; Ali

<p>
<hr>
<hr>
Date:     Tue, 29 Jun 93 14:04:36 EDT
From:     "John R. Anderson" &lt;jra@brl&gt;
To:       phd@BRL.MIL
cc:       acst@BRL.MIL, wm@BRL.MIL, jill@BRL.MIL,
          seyfertw%ccmail@tacom-emh1.army.mil, earl@BRL
Subject:  Intergraph/BRLCAD Translator
Message-ID:  &lt;9306291404.aa28542@WOLF.BRL.MIL&gt;

<p>
	I just talked to Bill Seyfert regarding the Intergraph/BRLCAD
translator that TACOM and FSTC sponsored. He gave me a brief description
of the status:

<p>
	The translators were written for Intergraph version 1.4 and BRLCAD
version 3.7. Translation to BRLCAD converts about a half dozen equivalent
solids directly to BRLCAD and the remainder are facetized and converted as
polysolids.  The translators are now being upgraded to Intergraph version
2.1 and BRLCAD version 4.0, and that effort is nearly finished.  The
current software runs only on an Intergraph workstation, but Mr. Seyfert
is procuring Intergraph software that will run on an SGI, and then intends
to port the translators to the SGI platform.  Translation to Intergraph
is also possible.  For a successful translation to BRLCAD, the Intergraph
user must follow some simple rules in the construction of the Intergraph
model.  For example, the user must build a solid model (not just surfaces
hanging in space), and the user must utilize Intergraphs layer capability
to create groups with names in the resulting brlcad model.

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV
U.S. Army Research Laboratory			Internet: jra@brl.mil
Aberdeen Proving Ground, MD  21005-5068		Phone: (410) 278-7267
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa15181; 30 Jun 93 16:01 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa16236; 30 Jun 93 15:16 EDT
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa15910; 30 Jun 93 15:06 EDT
Date:     Wed, 30 Jun 93 14:57:09 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       ali@archsci.arch.su.edu.au
cc:       cad@BRL.MIL
Subject:  Re: multi-user MGED
Message-ID:  &lt;9306301457.aa14048@WOLF.BRL.MIL&gt;

<p>

<p>
Ali writes -

<p>
&gt; I'm interested in adding concurrent multi-user capability
&gt; to MGED.

<p>
and Phil responded with some information about his new X interface
to MGED.

<p>
I have taken another approach in my team's "Virtual Reality for CAD"
project -- we support an arbitrary number of copies of MGED running,
and coordinate them via a program called VRMGR (Virtual Reality
Manager).  This permits multiple people to wander within a single
database, some using regular displays, some using stereo-capable
workstations, some using a workstation pair driving an HMD, and some
using an arbitrary number of workstations driving a "cave" display
surface.  Any combination is possible, and "overview" display stations
can also be instantiated, to see how the users are moving through
the virtual space.

<p>
Each MGED user has control over his own point of view, and can see the
other users as a simple wireframe "eye" token.

<p>
A prototype of this much is more-or-less working now, the real issues
of how to do distributed *editing* (rather than just viewing) remain
to be tackled.  Much of the infrastructure for that is already in place,
but there are some key issues in interface design and in MGED internals
that still need some work.

<p>
This is a low-priority project at the moment, but because it's fun it
gets continuing attention, and I have some big plans for this effort,
including integrating audio.

<p>
Naturally, a VR capability is most fun if you have polygons to render,
which makes the "VR for CAD" project take a distinct second seat to
the "finishing NMG Booleans" project....

<p>
There is a lot more that I could say about "VR for CAD".  I hope that
I've tantalized you a bit already!

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from wharf.brl.mil by WOLF.BRL.MIL id aa22873; 1 Jul 93 2:40 EDT
Received: from archsci.arch.su.EDU.AU by WHARF.BRL.MIL id aa03224;
          1 Jul 93 2:36 EDT
Received: from whitton.arch.su.EDU.AU by archsci.arch.su.EDU.AU (5.61+/5.17)
	id AA07862; Thu, 1 Jul 1993 16:35:22 +1000
Received: from [127.0.0.1] by whitton.arch.su.EDU.AU (5.61+/SMI-4.1)
	id AA14552; Thu, 1 Jul 1993 16:35:18 +1000
Message-Id: &lt;9307010635.AA14552@whitton.arch.su.EDU.AU&gt;
To: "John R. Anderson" &lt;jra@BRL.MIL&gt;, Mike Muuss &lt;mike@BRL.MIL&gt;,
    Patrick Haggard &lt;ph@physiol.ox.ac.uk&gt;
Cc: cad@BRL.MIL
Subject: brl-cad on Sun Sparcstations
Date: Thu, 01 Jul 93 16:35:14 +1000
From: ali@archsci.arch.su.edu.au

<p>

<p>
     Thanks for your help on compiling brl-cad on my sun sparcstation
under openwindows.  I modified the Cakefile.defs a slight bit to
compile under the "Sun with X11 only" option, but I still have
problems.  mged works fine, except that it flickers horribly when
rotating, zooming, etc.  Is it true that it does not do double
buffering because it's running under X?
     The main problem, however, is that rt doesn't work in mged. It
just messes up the screen alot and leaves the screen in black and
white mode when it stops.  Then if I re-attach X (or type fix),
everything goes back to normal, except that I have lots of debree
left on the screen where rt popped up a "window".

<p>
I've included the part of the Cakefile.defs file that I think is
relevant...

<p>
thanks,

<p>
-=&gt; Ali

<p>
#if defined(sparc)
/*    Sun-4 "SparcStation" hardware */
#     undef   sun
#     undef   sun4
#     define  MTYPE   sun4
#     define  BSD     43
#     define  HAS_TCP 1
#     define  OPTIMIZER       -O2
/*#   define  CC_DEFS -DAUTOSPEC      /* What does this do? */
#     define  LIBMALLOC       /* use vendor library */
#     define  LIBRT_TIMER     timer42
#     if 0
/*            Bare Sun configuration */
#             define  LIBFB_OBJS      if_remote if_sun
#             define  LIBFB_CONFIG    -DIF_REMOTE -DIF_SUN
#             define  LIBFB_LIBES     LIBPKG -lsuntool -lsunwindow -lpixrect
#             define  LIBRT_TIMER     timer42
#             define  MGED_OBJS       dm-sun
#             define  MGED_CONFIG     -DDM_SUNPW
#             define  MGED_LIBES      -lsuntool -lsunwindow -lpixrect
#     else
/*            Sun with X11 (aka "openwin").  Default for SunOS 4.1.1 */
#             define  LIBFB_OBJS      if_remote if_ab if_X if_sun
#             define  LIBFB_CONFIG    -DIF_REMOTE -DIF_AB -DIF_SUN \
                      -I/usr/openwin/include -DIF_X
#             define  LIBFB_LIBES     LIBPKG -lsunwindow -lpixrect -lsuntool\
                       -L/usr/openwin/lib -lX11
#             if 1
/*                    Sun with X11 only */
#                     define  MGED_OBJS       dm-sun dm-X
#                     define  MGED_CONFIG     -DDM_SUNPW -DDM_X
-I/usr/openwin/include
#                     define  MGED_LIBES -lsuntool -lsunwindow -lpixrect \
                              -L/usr/openwin/lib -lX11
#             else
/*                    Sun with X11 and XGL (an unbundled product) */
/*                    Note that at MSIC, -lgks may also be needed */
#                     define  MGED_OBJS       dm-xgl dm-X
#                     define  MGED_CONFIG     -DDM_XGL -DDM_X -I/usr/openwin/include
#                     define  MGED_LIBES      -lxgl -L/usr/openwin/lib -lX11
#             endif
#     endif
#     if 0
/*            "Unbundled" (i.e. "improved") compilers.  Use if you have them */
#             define  CC      /usr/lang/cc
#             define  FC      /usr/lang/f77
#     endif
#endif
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa23674; 1 Jul 93 4:05 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa26048; 1 Jul 93 3:48 EDT
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa26040; 1 Jul 93 3:47 EDT
Date:     Thu, 1 Jul 93 3:39:07 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       ali@archsci.arch.su.edu.au
cc:       Patrick Haggard &lt;ph@physiol.ox.ac.uk&gt;, cad@BRL.MIL
Subject:  Re: brl-cad on Sun Sparcstations
Message-ID:  &lt;9307010339.aa23335@WOLF.BRL.MIL&gt;

<p>

<p>
&gt;     The main problem, however, is that rt doesn't work in mged. It
&gt; just messes up the screen alot and leaves the screen in black and
&gt; white mode when it stops.  Then if I re-attach X (or type fix),
&gt; everything goes back to normal, except that I have lots of debree
&gt; left on the screen where rt popped up a "window".

<p>
Sounds like you are using the raw Sun "pixrect" interface (/dev/sun),
rather than the X11 interface to the framebuffer.  You can verify that
this is in fact the case by running "fbhelp" from the shell once, and
examining the lower half of it's output (after the "=== Current
Selection ===") message.

<p>
&gt; I've included the part of the Cakefile.defs file that I think is
&gt; relevant...

<p>
This was very helpful.  Thanks!  Where you said:

<p>
/*            Sun with X11 (aka "openwin").  Default for SunOS 4.1.1 */
#             define  LIBFB_OBJS      if_remote if_ab if_X if_sun
#             define  LIBFB_CONFIG    -DIF_REMOTE -DIF_AB -DIF_SUN \
                      -I/usr/openwin/include -DIF_X
#             define  LIBFB_LIBES     LIBPKG -lsunwindow -lpixrect -lsuntool\
                       -L/usr/openwin/lib -lX11

<p>
remove the if_sun, -DIF_SUN stuff, so that it now looks like this:

<p>
/*            Sun with X11 (aka "openwin").  Default for SunOS 4.1.1 */
#             define  LIBFB_OBJS      if_remote if_ab if_X
#             define  LIBFB_CONFIG    -DIF_REMOTE -DIF_AB \
                      -I/usr/openwin/include -DIF_X
#             define  LIBFB_LIBES     LIBPKG \
                       -L/usr/openwin/lib -lX11

<p>
This will prevent you from accidentally getting the SunTools interface
by default.

<p>
Alternatively (requiring no recompilation), remember to set your
environment variable FB_FILE before starting up MGED or other BRL-CAD
tools.

<p>
csh:	setenv FB_FILE /dev/X
sh:	FB_FILE=/dev/X; export FB_FILE

<p>
I hope this helps.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa25105; 1 Jul 93 8:29 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa29940; 1 Jul 93 8:29 EDT
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa29623; 1 Jul 93 8:20 EDT
Date:     Thu, 1 Jul 93 8:12:24 EDT
From:     "John R. Anderson" &lt;jra@BRL.MIL&gt;
To:       ali@archsci.arch.su.edu.au
cc:       cad@BRL.MIL
Subject:  Re:  brl-cad on Sun Sparcstations
Message-ID:  &lt;9307010812.aa24961@WOLF.BRL.MIL&gt;

<p>
Ali,

<p>
&gt;      Thanks for your help on compiling brl-cad on my sun sparcstation
&gt; under openwindows.  I modified the Cakefile.defs a slight bit to
&gt; compile under the "Sun with X11 only" option, but I still have
&gt; problems.  mged works fine, except that it flickers horribly when
&gt; rotating, zooming, etc.  Is it true that it does not do double
&gt; buffering because it's running under X?

<p>
	I believe that is just a characteristic of graphics under X.

<p>

<p>
&gt;      The main problem, however, is that rt doesn't work in mged. It
&gt; just messes up the screen alot and leaves the screen in black and
&gt; white mode when it stops.  Then if I re-attach X (or type fix),
&gt; everything goes back to normal, except that I have lots of debree
&gt; left on the screen where rt popped up a "window".

<p>
	Try setting your framebuffer to X.  If you are using the Bourne
shell do:
	FB_FILE=/dev/Xl
	export FB_FILE
Or, if you use a csh do:
	setenv FB_FILE /dev/Xl

<p>
	Also, try the "fbhelp" command for more info.

<p>

<p>
				-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV
U.S. Army Research Laboratory			Internet: jra@brl.mil
Aberdeen Proving Ground, MD  21005-5068		Phone: (410) 278-7267
<hr>
<hr>
Date:     Tue, 6 Jul 93 15:45:31 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
To:       Keith Applin &lt;keith@brl&gt;
cc:       Andre Joanisse &lt;andrej@venus.resntl.bhp.com.au&gt;, keith@BRL.MIL,
           mmonk@BRL.MIL, mike@BRL.MIL
Subject:  Re: BRL-CAD Getting Started Guide????
Message-ID:  &lt;9307061545.aa24578@WOLF.BRL.MIL&gt;

<p>

<p>
I suspect that what Andre was really asking for was a pointer to the
examples on how to use MGED.

<p>
In Vol IV (MGED User's Manual), try looking at chapters 13 and 14,
then refer back to earlier chapters in that manual for details.

<p>
	Best,
	 -Mike
<hr>
<hr>
Date:     Tue, 13 Jul 93 2:22:44 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
To:       ali@archsci.arch.su.edu.au
cc:       mike@BRL.MIL, phil@BRL.MIL, cad@BRL.MIL
Subject:  Re: mu_mged (last one)
Message-ID:  &lt;9307130222.aa28801@WOLF.BRL.MIL&gt;

<p>

<p>
&gt; 	Since I haven't been receiving *any* responses to my questions, this
&gt; will be the last time I will post a general mailing to cad@brl.mil.

<p>
Well, I answered at least one of your earlier messages, at least to say
that you were welcome to ask away, and that the developers really could
not commit to answering such detailed questions with any kind of
promptness -- we have quite a few other things going on right now,
and being only 4, can't invest too much time providing help to folks
who obtained "no support" distributions....  I regret that we can't
offer more help, but we can't. If we provided each of our 800 user sites
even a few hours of help, we wouldn't have any time left for our own
projects.  I hope you can appreciate our limitation.

<p>
You are engaged in a difficult task (multi-user geometry editing).
There are many different strategies that you might adopt for
implementing this within MGED.  You have not made it entirely clear
what strategy you are considering, which makes it hard to provide
concise suggestions.

<p>
&gt; I also understand (I think) how the dbase works and when it is
&gt; accessed.

<p>
This is one of the main benefits that you obtain from having the source
code -- you can study the code and figure things out for yourself.
I'm glad it is yeilding some of it's secrets to you, already. :-)

<p>
&gt; However, I am still in desperate need of getting in touch with
&gt; someone who "understands" how the actual memory management works and
&gt; perhaps why it was designed in certain ways in certain places...

<p>
I designed all the memory management;  if you have a specific question
that has a brief answer, I'll try to reply.

<p>
Much of the memory management code is more than 10 years old, and was
designed to run on PDP-11 processors with limited address space. Thus,
the notion of "database granules" (128 bytes each) which can be
processed one at a time.  This mode of operating is no longer necessary,
but not all the code has been converted yet.   So, you will see both the
"old way" db_get()/db_put() usage, as well as the "new way" usage of
db_get_external()/db_put_external() to move 'objects' between memory and
the ".g" database file.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa03028; 19 Jul 93 21:41 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa25126; 19 Jul 93 21:25 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa25098; 19 Jul 93 21:16 EDT
Received: from archsci.arch.su.EDU.AU by WHARF.BRL.MIL id aa11248;
          19 Jul 93 21:02 EDT
Received: from young.arch.su.EDU.AU by archsci.arch.su.EDU.AU (5.61+/5.17)
	id AA02148; Tue, 20 Jul 1993 11:02:40 +1000
Received: from [127.0.0.1] by young.arch.su.EDU.AU (5.61+/SMI-4.1)
	id AA11556; Tue, 20 Jul 1993 11:02:38 +1000
Message-Id: &lt;9307200102.AA11556@young.arch.su.EDU.AU&gt;
To: cad@BRL.MIL
Subject: Re:  converting dxf files to brl-cad files
Date: Tue, 20 Jul 93 11:02:38 +1000
From: ali@archsci.arch.su.edu.au

<p>

<p>
Yes, I do realize that it would require major redesign, but I was hoping
somebody had done it.  Actually, I was right!  Unfortunately, the price is
not right...

<p>
-=&gt; Ali

<p>
p.s.  I don't really need it anymore, so I didn't reply to him...

<p>
------- Forwarded Message

<p>
Return-Path: olasov@cs.columbia.edu
Received: from cs.columbia.edu by archsci.arch.su.EDU.AU (5.61+/5.17)
	id AA21686; Mon, 19 Jul 1993 08:58:26 +1000
Received: from ground.cs.columbia.edu by cs.columbia.edu
(5.65c/0.6/jba+ad+jtt) with SMTP
	id AA21871; Sun, 18 Jul 1993 18:58:19 -0400
Received: by ground.cs.columbia.edu id AA03805
  (5.65c/IDA-1.4.4.5/jba/jtt/ad for ali@archsci.arch.su.edu.au); Sun,
18 Jul 1993 18:58:13 -0400
Date: Sun, 18 Jul 1993 18:58:13 -0400
From: Benjamin Olasov &lt;olasov@cs.columbia.edu&gt;
Message-Id: &lt;199307182258.AA03805@ground.cs.columbia.edu&gt;
To: ali@archsci.arch.su.edu.au
Subject: converting Autocad files to .asc files (from BRL-CAD)

<p>
My consulting company has an AutoCad -&gt; BRL translator (.dwg -&gt; .asc)
which it sells commercially.  The price is $500 US.

<p>
Ben

<p>

<p>

<p>
------- End of Forwarded Message

<p>
<hr>
<hr>
Date:     Mon, 19 Jul 93 18:56:05 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
To:       ali@archsci.arch.su.edu.au
cc:       Mike Muuss &lt;mike@brl.mil&gt;, ACST@BRL.MIL
Subject:  Re: selection/illumination
Message-ID:  &lt;9307191856.aa01693@WOLF.BRL.MIL&gt;

<p>

<p>
&gt; 	In other words, how can I do something to the effect of "e
&gt; /tank/fuel" instead of either "e tank" or "e fuel" (which would
&gt; ignore matrices higher up in the tree)?

<p>
Ah, an easy one!  How about just doing "e tank/fuel" (or whatever the
partial path spec is).  That works.  Or, better still, see my remarks
below.

<p>
&gt; An even shorter short-ish mged hacking question:
&gt; 	from within db_put(), how can I find the complete pathname
&gt; of the solid being "put"?

<p>
You can't do it, that far down in the library.  Best you can do is to
get the name of the object being written (dp-&gt;d_namep).  In any case,
this is what you actually need, because you should then go and search
the MGED solid table for all objects on the screen that refer to this
database item, and redraw those "involved" solids.  There is handy
support for this operation in the form of subroutine
replot_modified_solid() in file mged/dodraw.c

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa04448; 20 Jul 93 0:41 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa25586; 19 Jul 93 23:44 EDT
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa25583; 19 Jul 93 23:39 EDT
Date:     Mon, 19 Jul 93 23:27:28 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       ali@archsci.arch.su.edu.au
cc:       CAD@BRL.MIL
Subject:  Re: selection/illumination
Message-ID:  &lt;9307192327.aa04119@WOLF.BRL.MIL&gt;

<p>

<p>
Ali writes -

<p>
&gt; Let's try a yes/no version of the question: when db_put stores s214,
&gt; from accepting changes on /tank/computer/r213/s214, does that mean that
&gt; all references to s214 are changed?

<p>
Alas, he didn't succeed in making it yes/no.  Grin!

<p>
There are two kinds of editing in MGED:  "solid edit", which transforms
the parameters of a *leaf* node (solid) in the tree, and "object edit",
which modifies the 4x4 transformation matrix stored along one *arc* of
the tree.

<p>
So, if you did a solid edit on "s214", all instances of that solid would
change.  If you did an object edit on "/tank/computer/r213/s214" and
replaced the matrix at the arc "r213/s214", then only that instance
would change.

<p>
At present there is no way to specify changing an leaf-node's
paramter(s) in an object edit.  Instancing is primarily used for
repeating many copies of identical parts.  Some modelers (e.g. Harry
Reed & crew) tend to avoid instances, while others (e.g. Jim Hunt &
crew) couldn't live without them.

<p>
I agree that the instancing capability could be more flexible, but
that leads the discussion in the direction of a non-global name space
or an 'interpreted' database, neither of which are 'minor' changes to
the design of the system.  As it stands now, these lacks don't seem to
be a serious hindrance, so this is not a 'hot topic', although we do
kick it around from time to time.

<p>
	Best,
	 -Mike

<p>
<hr>
<hr>
Received: from wumpus.brl.mil by WOLF.BRL.MIL id aa24107; 23 Jul 93 9:23 EDT
Date:     Tue, 20 Jul 93 9:31:50 EDT
From:     Carl Moore &lt;cmoore@BRL.MIL&gt;
To:       Mike Muuss &lt;mike@BRL.MIL&gt;
cc:       ali@archsci.arch.su.edu.au, CAD@BRL.MIL
Subject:  Re: selection/illumination
Message-ID:  &lt;9307200931.aa01914@WUMPUS.BRL.MIL&gt;

<p>

<p>
I noticed the comments on instancing.  I have had cases where I "inherited"
instancing in a description, and I started getting annoyed when I tried to
display a low-level solid and it did not appear where I thought, due to my
missing a transformation at a higher level in the tree.  Solution: I set
up at least one transformation-free path leading down to each solid.
<hr>
<hr>
Received: from vmb.brl.mil by WOLF.BRL.MIL id aa16792; 4 Oct 92 21:53 EDT
Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20069; 4 Oct 92 21:32 EDT
Received: from wharf.brl.mil by VMB.BRL.MIL id aa20048; 4 Oct 92 21:24 EDT
Received: from relay1.UU.NET by WHARF.BRL.MIL id aa08733; 4 Oct 92 20:10 EDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
	(5.61/UUNET-internet-primary) id AA00151; Sun, 4 Oct 92 20:11:26 -0400
Received: from results.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 201007.22878; Sun, 4 Oct 1992 20:10:07 EDT
Received: by results.com (5.64/A/UX-AMR-1.0)
	id AA11799; Sun, 4 Oct 92 20:08:40 EDT
Date: Sun, 4 Oct 92 20:08:40 EDT
From: BRL-CAD Users Conference &lt;confer@results.com&gt;
Message-Id: &lt;9210050008.AA11799@results.com&gt;
To: cad@BRL.MIL
Subject: BRL-CAD Users Conference Regestration and Schedule

<p>
		First Annual BRL-CAD Users Conference
			November 4-6, 1992
			Omni International Hotel
		Inner harbor, Baltimore, Maryland, USA

<p>
This two and a half day conference will cover many topics of interest to
users of the BRL-CAD Package. While other symposia have focused on
presenting results of research and various theoretical applications,
this conference will teach attendees how to use the power of BRL-CAD
to accomplish their own tasks.

<p>
Presentations, papers, and tutorials will focus on a variety of subjects
for users at all skill levels. Subject range from introductory materials
for persons new to CSG to more esoteric subjects such as generation of
synthetic images for the simulation of thermal and laser radar sensors.
Intermediate topics will cover such practical considerations as printing
images, animation, vulnerability analysis, and specific information on
tools such as MUVES, FRED, LIBRT and others.

<p>
The conference fee includes a superb banquet of New York Strip Sirloin
(vegetarian alternative available), spinach salad, crab bisque (A
Maryland speciality), vegetables and potato, and a wonderful strawberry
cheesecake, all served with red or white wine.  Two lunches, three
Continental breakfasts, numerous breaks, and a hospitality suite are
also provided with equally handsome comestibles.

<p>
The Omni International Hotel provides a business center, gift shop, and
exercise room, with skywalk access to the waterfront with its many
historic sights, museums, theaters, restaurants, shops, and ships.
within the hotel are Jackies Cafe which offers American cuisine and The
Corner Bar with its Library of fine drink selections and complimentary
hors d'oeuvres during week day happy hour.

<p>
-----------------------------------------------------------------------
			1992 BRL-CAD USERS Conference
				Schedule

<p>
November 3rd, 1992

<p>
1200-1700 Check-In
2000-0100 Informal Reception hosted by RESULTS Now, Inc.

<p>
November 4th, 1992

<p>
0800-0900 Continental Breakfast.
0900-0915 Welcome and Announcements
0915-1000 "Practices and Standards in the Construction of BRL-CAD
	Target Descriptions",  by Dr. Paul H. Deitz, Chief, Ballistic
	Vulnerability/Lethality Division, Army Research Laboratory and
	Mr. Keith A. Applin, Ballistic Vulnerability/Lethality Division,
	Army Research Laboratory.
1000-1015 Break
1015-1100 "Using BRL-CAD to Generate Synthetic Images for the Simulation
	of Thermal and Laser Radar Sensors", John Dome, Electro-Optics
	Division, U.S. Army Night Vision Laboratory
1105-1200 Three Short Presentations
	"Target Damage Modeling in EVA-3D", by R. Kathryn Tucker and
	Kellye C. Frew, Applied Research Associates, Inc.
"Frangible Munition and the BRL-CAD Package; A Successful Combination",
	 by Tom Keij, TNO Defense Research, Prins Maurits Laboratory
"An Overview of the Modular Unix-Based Vulnerability Estimation Suite
	(MUVES)", by Karen R. Murray, Ballistic Vulnerability/Lethality
	Division, Army Research Laboratory
1200-1315 Lunch
1315-1400 "In-the-Field Modeling", by Harry J. Reed, Geometric Solutions, INC.
1405-1450 "Radar Range Profile Computation for BRL-CAD Models", Dr. S.W. Lee
	and David Reeves, University of Illinois, Dennis J. Andersh, USAF,
	C.L. Yu, Naval Pacific Missile Test Center
1450-1515 Break
1515-1600 "End-to-End Sensor Modeling Using BRL-CAD 4.0 with the Faceted
	Region Editor (FRED)"  by Jack Jones, U.S. Army Tank Automotive
	Command
1605-1700 "Getting BRL-CAD Images Printed", by Christopher T. Johnson,
	Paladin Software
1800-1930 Banquet Dinner
1930-2000 Key Note Address, Dr. Richard Vitali, Acting Director,
	Army Research Laboratory
2000-0100 Hospitality Suite/Reception Hosted by RESULTS Now, Inc.

<p>
November 5, 1992

<p>
0800-0900 Continental Breakfast
0900-0915 Announcements
0915-1000 "Directions in the BRL-CAD Package" (Tentative Title),
	Michael J. Muuss, Ballistic Vulnerability/Lethality Division,
	Army Research Laboratory
1000-1015 Break
1015-1100 "Blueprints to BRL-CAD; The User Interface", Erik Lane,
	Student Contractor, Ballistic Vulnerability/Lethality Division,
	Army Research Laboratory
1105-1200 Three Short Presentations
	"Proliferation Concerns in Geometric Modeling", Victor Cericole, Jr.
	Geometric Solutions, INC.
"I/EMS to BRL-CAD Translation: Converting from a B-REP Modeler to a
	CSG Modeler", Andrew J. Foglia, Intergraph Corporation, Federal
	Systems Division
"Revision Control System (RCS) Configuration Management for BRL-CAD Target
	Descriptions", Susanne Muuss, Army Research Laboratory
1200-1330 Lunch
1330-1700 Tutorials (Concurrent Offerings)

<p>
1)	"Animation with BRL-CAD", Christopher T. Johnson, Paladin Software
2)	"How to Construct a Simple Model Using BRL-CAD", Victor Cericole, Jr.,
	Geometric Solutions, INC.
3)	"How to Use LIBRT, LIBWDB, and LIBFB", Harry J. Reed,
	Geometric Solutions, INC.
4)	"Understanding Non-Manifold Geometry" (Tentative Offering)

<p>
2000-0100 Hospitality Suite/Reception Hosted by RESULTS Now, Inc.

<p>
November 6th, 1992

<p>
0800-0900 Continental Breakfast
0900-1230 Tutorials Repeated
1230-1300 Fare Well

<hr>
<hr>
Date:     Fri, 13 Aug 93 14:26:39 EDT
From:     "Lee A. Butler" &lt;butler@brl&gt;
To:       Edwin O. Davisson &lt;davisson@brl.mil&gt;
cc:       mike@BRL, pjt@BRL, jra@BRL, stay@BRL, gdurf@BRL, butler@BRL
Subject:  Re:  nearest edge algorithm
Message-ID:  &lt;9308131426.aa26554@WOLF.BRL.MIL&gt;

<p>
Ed,

<p>
&gt;	In your algorithm for classifying a point as in or out of a
&gt;face, Mike claims you look at the nearest edge.  How do you find that
&gt;nearest edge?  Do you assume the polygonal boundary is convex?  If
&gt;you use a similar approach to what was being described on the sphere
&gt;yesterday, you may have a problem.

<p>
The current version of the algorithm is something like this:

<p>
Given:
	 a "plane point" in the plane of a face,
	 a set of edges in the plane

<p>
For each edge in the face, determine the point of closest approach (PCA) of
the edge to the "plane point".  Remember the edge/PCA pair with the smallest
distance to the "plane point."

<p>
iff the "closest" edge has its PCA along the length of the edge, or the "plane
    point" is on the edge:
	A) if the "plane point" is on the edge, declare it to be "on" the
		face", otherwise....
	B) Determine if the plane point is "left" of the use of the edge in
		the normal-ward use of the face.
		1) form the "left vector" for the edgeuse.
		2) form a vector from the endpoint of the edgeuse to the
			"plane point"
		3) form the Dot product of these two vectors.

<p>
			If the sign of the Dot product is positive or zero,
			the plane point is inside the surface area of the
			face, otherwise it is outside the surface area of
			the face.


<p>
iff the "closest" edge has its PCA at a vertex (end point) and the vertex is
    NOT coincident with the plane point:
	A) form the vector from the endpoint to the "plane point".
	B) for each edgeuse of the face which touches the vertex:
		form the unit "left" vector for the edgeuse, (which points
		in the direction of the face area WRT the edge).
	C) find the edgeuse whose left vector has the smallest Dot product
		with the vector to the "plane point."

<p>
			If the sign of the Dot product is positive or zero,
			the plane point is inside the surface area of the
			face, otherwise it is outside the surface area of
			the face.

<hr>
<hr>
Date:     Fri, 20 Aug 93 5:39:06 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
To:       Anthony Giancola &lt;kachina!tony@cs.unm.edu&gt;, tony@ObjectSci.com
cc:       mike@BRL.MIL, tony@cs.unm.edu
Subject:  Re: BRL CAD under Solaris 2.2
Message-ID:  &lt;9308200539.aa28134@WOLF.BRL.MIL&gt;

<p>

<p>
Sorry, we have not had any opportunity to bring BRL-CAD up under Solaris
2.2, that I am aware of.  Your best bet would be to remove all LIBFB and
MGED display options from Cakefile.defs, and proceed from there.  Once
you get that working, adding back (say) X windows support shouldn't be
too hard.

<p>
That is to say, delete all lines starting with:

<p>
#	if 1
/*		Bare Sun configuration */
#		define	LIBFB_OBJS	if_remote if_sun

<p>
down through

<p>
#		endif
#	endif

<p>
Thats about 32 lines worth (judging by eye).

<p>
	Best,
	 -Mike Muuss
<hr>
<hr>
Date:     Mon, 23 Aug 93 13:00:06 EDT
From:     "John R. Anderson" &lt;jra@brl&gt;
To:       acst@BRL.MIL
Subject:  New code in "nmg_misc"
Message-ID:  &lt;9308231300.aa27795@WOLF.BRL.MIL&gt;

<p>
	I have added a routine called "nmg_break_long_edges" to "nmg_misc.c".
        This codes looks for situations as illustrated:

<p>
	    *-------&gt;*--------&gt;*---------&gt;*
	    *&lt;----------------------------*

<p>
        where one long edgeuse (the bottom one above) and two or more
        shorter edgeusess (the tops ones) are collinear and have the same
        start and end vertices.  The code breaks the longer edgeuse into
        ones that can be radials of the shorter ones. I ran into this
	situation in converting the "tankill" geometry.

<p>

<p>

<p>
			-John

<p>
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa15809; 9 Sep 93 14:33 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa17804; 9 Sep 93 13:46 EDT
Received: from worm.brl.mil by WALRUS.BRL.MIL id aa17588; 9 Sep 93 13:42 EDT
Date:     Thu, 9 Sep 93 13:35:40 EDT
From:     Susan Coates (VLD) &lt;scoates@BRL.MIL&gt;
To:       cad@BRL.MIL
cc:       scoates@BRL.MIL
Subject:  Rotating a Solid
Message-ID:  &lt;9309091335.aa08483@WORM.BRL.MIL&gt;

<p>

<p>
Sven Schroeter, tools-administrator.
email schroeter@ls7.informatik.uni-dortmund.de

<p>
writes:

<p>
&gt; i've just installed brl-cad on a sun4 system.
&gt; After compiling and installing everything right (?!),
&gt; i've got som problems :
&gt;                         1. how can i rotate a single
&gt;                            solid, when i chose the rotate-
&gt;                            function in the edit-solid menu.

<p>
	Choose the solid to edit.
	Select rotate with the mouse.
	Then type 'p x y z'
		Where x is the rotation about the x-axis, y is the
		rotation about the y-axis, and z is the rotation
		about the z-axis.  For example 'p 0 0 -10' rotates
		the solid -10 degrees about the z-axis.  I find
		it easier to rotate about one axis and accept the
		edit and then do a rotation about the next axis.
		I do this because I can not keep straight which
		rotation comes first (I want to say it is about
		the z-axis).  Also I have trouble visualizing
		more than one rotation at a time.  The rotation
		must be accepted before another rotation is
		typed in.  For example if the following commands
		are issued.
			p 0 0 -10
			p 0 0 -20
		The result is that the solid is rotated -20
		degrees about the z-axis not -30 degrees.
	An alternate way is to use the sliders.  Select sliders
		and seven sliders appear at the top of the screen;
		xslew, yslew, zslew, zoom, xrot, yrot, zrot.  The
		solid may be rotated using xrot, yrot, and zrot.
		Click the mouse to the left or right of the rotate
		sliders to get the solid to rotate.  On my SUN this
		is extremely difficult I can't see the sliders (I
		had to log on to an sgi to read what they said).
		Select Zero Sliders to stop or click the mouse right
		in the middle of the slider.

<p>
I hope this answer helps.  I don't know anything about the second
problem you are experiencing.

                                        Susan Coates

<p>

<p>
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa16044; 9 Sep 93 15:00 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa19049; 9 Sep 93 14:19 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa18980; 9 Sep 93 14:16 EDT
Received: from ATHENA-AS-WELL.MIT.EDU by WHARF.BRL.MIL id aa15343;
          9 Sep 93 14:13 EDT
Received: from W20-575-7.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA19036; Thu, 9 Sep 93 14:12:51 EDT
Received: by w20-575-7.MIT.EDU (5.0/4.7) id AA05685; Thu, 9 Sep 93 14:12:39 EDT
Message-Id: &lt;9309091812.AA05685@w20-575-7.MIT.EDU&gt;
To: Adm diverser tools &lt;tools@frenet.informatik.uni-dortmund.de&gt;
Cc: CAD@BRL.MIL
Subject: Re: brl-cad on sun4
In-Reply-To: Your message of Thu, 09 Sep 93 18:37:34 +0200.
             &lt;9309091637.AA09999@frenet.informatik.uni-dortmund.de&gt;
Date: Thu, 09 Sep 93 14:12:37 EDT
From: Ali Alavi &lt;alialavi@athena.mit.edu&gt;
Content-Length: 724

<p>
Sven,

<p>
&gt;                         2. calling rt as key-command colors
&gt;                            the desktop black with red borders
&gt;                            to the windows, paints a picture
&gt;                            which is 50% right and 50% wrong
&gt;                            and returns to a b/w desktop.
&gt;                            The rt-window doesn't refresh.

<p>
I've had that problem before.  the way you fix it is by typing "fbhelp" (which
is in the fb directory).  It should tell you how to set env options that should
fix the problem.  I know you're on a sun4, but what os version are you using?
Sunview or OpenWindows or Solaris?  What options did you compile with?  I was
running Openwindows...

<p>
-=&gt; Ali
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa20123; 9 Sep 93 19:25 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa25041; 9 Sep 93 18:55 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa25026; 9 Sep 93 18:52 EDT
Date:     Thu, 9 Sep 93 18:48:47 EDT
From:     "Harry Reed Jr." (GSI|phd) &lt;reed@BRL.MIL&gt;
To:       tools@frenet.informatik.uni-dortmund.de
cc:       cad@BRL.MIL
Subject:  Problems
Message-ID:  &lt;9309091848.aa18082@WHARF.BRL.MIL&gt;

<p>

<p>
Sven Schroeter,

<p>
	There is a problem with selecting solids on a SUN machine using the
current version of BRL-CAD.  The general process of selecting a solid for
rotation is:

<p>
	1) Display the items on the screen that you want to edit or will need
	for determining how the solid of interest should be processed.  For
	example, if you want to rotate a cylinder and translate it to rest
	on the side of a box, then it may be interesting to not only
	display the cylinder, but the box as well.  When the cylinder is
	modified, then the immediate feedback of the box and cylinder (in its
	new rotation and orientation) will uickly confirm that the processing
	action on the cylinder was either a success or a failure.

<p>
	2) Select "solid edit" from the pop down menu.  This action will
	place you in solid edit state rather than the initial (base) viewing
	state.

<p>
	3) Since many different solids can be illuminated at one time, MGED
	expects you to select a particular solid for editing.  One selects
	a particular solid by moving the cursor up and down until the desired
	solid outline is either changed in color (red to white on an SGI
	machine) or is redrawn with a tripple line thickness.

<p>
	Once the solid you want to edit is highlighted by either of the
	previously mentioned methods, simply click on the center mouse
	button once to inalize the selection.

<p>
	4) Select rotate from the pop down menu and either type in the
	desired X, Y, or Z axis rotation, or use the sliders or graphics
	station peripheral control knobs.  Please note that if you type in
	an X, Y, or Z axis rotation value, you must exit rotation mode and
	re-enter rotation mode if a further rotation is desired.  Otherwise,
	the old (previous) rotation will be replaced by the new rotation as if
	the old rotation never occurred.

<p>
	5) Once rotated correctly, select the accept edit field in the pop down
	menu an the solid edit is complete.

<p>
	Two final points, I hope that you understand the difference between
solids, regions, and groups in a BRL-CAD CSG target description and that you
are not referring to regions or group items as some complex surface editors
often do.  Secondly, there are more direct and sometimes easier to use
methods for editing solids such as MGED's "sed" command that were not
discussed here.  As always, each method has its strengths and weaknesses.

<p>
	For a more indepth answer to your problem (if you want one), feel
ffree to call us at 1-800-598-BRLCAD (2752).

<p>
Thanks,

<p>
Harry J. Reed
Geometric Solutions, INC.
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa03013; 10 Sep 93 8:08 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa01517; 10 Sep 93 7:26 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa01514; 10 Sep 93 7:24 EDT
Received: from sun2.nsfnet-relay.ac.uk by WHARF.BRL.MIL id aa03656;
          10 Sep 93 7:13 EDT
Via: uk.ac.oxford.prg; Fri, 10 Sep 1993 12:12:37 +0100
Received: from oxphys.physiol (oxphys-gate.physiol) by prg.oxford.ac.uk
          id AA06515; Fri, 10 Sep 93 12:12:23 +0100
Received: from galen.physiol.physiol
          by uk.ac.oxford.physiology (4.1/physiol 1.2m (20-Jun-90)) id AA22393;
          Fri, 10 Sep 93 12:01:40 BST
Date: Fri, 10 Sep 93 12:01:40 BST
From: Patrick Haggard &lt;ph@physiol.ox.ac.uk&gt;
Message-Id: &lt;9309101101.AA22393@uk.ac.oxford.physiology&gt;
To: alialavi@athena.mit.edu, reed@BRL.MIL
Subject: Re: brl-cad on sun4
Cc: cad@BRL.MIL

<p>
Er, yes, but the problem with the X interface is that you seem to need
xgl _v2.0_, which a lot of sites don't have (it's unbundled), and which
is not upwards compatible with the current xgl (v3.0).  This was a
sufficient deterrent to send me back to suntools.
Patrick Haggard --- ph@physiol.ox.ac.uk [WORLD] ph@uk.ac.ox.physiol [JANET]
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa01661; 15 Sep 93 20:54 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa09323; 15 Sep 93 20:11 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa09243; 15 Sep 93 20:01 EDT
Date:     Wed, 15 Sep 93 19:47:52 EDT
From:     "Harry Reed Jr." (GSI|phd) &lt;reed@BRL.MIL&gt;
To:       M.Brand@fel.tno.nl
cc:       cad@BRL.MIL
Subject:  FRED
Message-ID:  &lt;9309151947.aa20278@WHARF.BRL.MIL&gt;

<p>

<p>
Dr.M.G.E.Brand

<p>
	In response to your questions concerning the FRED tool, we find it
interesting, although not the most mathematically complete approach, but
uite useful for general application none the less.  Perhaps you would like
to speak directly with the creator of FRED at TACOM.  His name is Jack
Jones (a good friend of mine) and his number is (313)574-7654 USA.  If I
can answer more questions about the methods we at GSI use to convert BRL-CAD
databases into FACETS or B-surfaces, or why you may want to wait for NMG
technology to be completed, please call us at 1-800-598-BRLCAD (2752).

<p>
							Thanks,
							Harry J. Reed
							Geometric Solutions, INC
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa20573; 25 Sep 93 11:26 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa23334; 25 Sep 93 11:24 EDT
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa23283; 25 Sep 93 11:16 EDT
Date:     Sat, 25 Sep 93 11:13:57 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  LIBFB Interface Change on ANSI compilers
Message-ID:  &lt;9309251113.aa20302@WOLF.BRL.MIL&gt;

<p>

<p>
This evening, in an attempt to start porting BRL-CAD to our new SGI
Power Challenge machine running IRIX 5, I once again had to wrestle with
the issue of ANSI function prototypes for the routines in LIBFB.  We had
previously said that routines like fb_write() took arguments of type
RGBpixel[].  RGBpixel was a typedef for an unsigned char[3] array.  As
Doug Gwyn pointed out when I brought this up the last time, arrays are
not fundamental types in C, and so this construction can be a bit
awkward.

<p>
With the necessity for (and desireability of) using function prototypes
upon us, the difficulty presented by the old method was just too great.
So, in the name of simplicity, I converted all the pixel parameters
to type (unsigned char *), which more simply describes the "packed byte
array" in which pixels are stored.  This is better than saying "RGBpixel
pp[]" everywhere, which would have had to be dereferenced as pp[i][RED].

<p>
I've changed h/fb.h, all of libfb/, all of fb/, all of util/, and
odds and ends elsewhere to account for this change.  Next time I need a
break from working on NMGs I'll try to recompile all the sources, and
chase down any other code that needs to be modified as a result of this.

<p>
Not surprisingly, a lot of the fb/ code was already using arrays of
chars, so making this is proper way to do things actually fits well with
a nice chunk (but certainly not all) of our current practice.

<p>
I'm sure that there are some of you who will find this change to be
disturbing, because it implies that some existing code might not work
with the new LIBFB interface.  First, let me note that if you are
not using an ANSII C compiler, this is an invisible change.  And, if you
*are* using an ANSII C compiler, you can't get the benefits of function
prototypes without this change.  Function prototypes are no panacea, but
I'm sufficiently pleased with their utility to insist that they be used
on all major interfaces.

<p>
I converted about 60 complete source modules in the course of about 6
hours, so in general changing a source file or two shouldn't take long.
I really didn't want this change, I'm not looking for change just for
the sake of change.  This is something that is being forced upon us by
the increasing availability of ANSI C compilers.

<p>
I think I've gotten everything in LIBFB except the X Windows module
(libfb/if_X.c) ported to IRIX 5 already -- and X is only complaining
about one thing (dpy-&gt;fd reference).  Should be easy to fix.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vgr.brl.mil by WOLF.BRL.MIL id aa06906; 27 Sep 93 15:21 EDT
Date:     Mon, 27 Sep 93 19:15:08 GMT
From:     Doug Gwyn (ACISD/MCSB) &lt;gwyn@BRL.MIL&gt;
To:       Mike Muuss &lt;mike@BRL.MIL&gt;
cc:       CAD@BRL.MIL
Subject:  Re:  LIBFB Interface Change on ANSI compilers
Message-ID:  &lt;9309271915.aa19756@VGR.BRL.MIL&gt;

<p>
The only reasonable alternative would be to change RGBpixel to be a
structure type, but that means each RGBpixel could have from zero to
five additional unusable "padding" bytes (most likely 1 byte) added
by the compiler, which would (a) waste space and (b) be incompatible
with existing code that handles pixel data as a packed byte array.
Thus, while (a) might be deemed acceptable when designing new software
(especially since it might lead to faster generated code),
consideration (b) pretty much forces the solution Mike chose.

<p>
The "flavor" of code using constructs like pp[i][RED] can be retained
by defining suitable macros, e.g.:

<p>
typedef unsigned char RGBpixel[3];	/* still useful! */
#define RED	0
#define GREEN	1
#define BLUE	2

<p>
#define PIX(a,i,c)	((RGBpixel *)(a))[i][c]
#define	PIX_RED(a,i)	PIX(a,i,RED)
#define	PIX_GREEN(a,i)	PIX(a,i,GREEN)
#define	PIX_BLUE(a,i)	PIX(a,i,BLUE)

<p>
#define PP(i,c)		PIX(pp,i,c)

<p>
	PIX(pp,i,RED)	/* was: pp[i][RED] */
	PIX_RED(pp,i)	/* ditto */
	PP(i,RED)	/* ditto */
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa06606; 22 Sep 93 16:21 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa17879; 22 Sep 93 15:42 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa17703; 22 Sep 93 15:34 EDT
Received: from Sun.COM by WHARF.BRL.MIL id aa19755; 22 Sep 93 15:27 EDT
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA18018; Wed, 22 Sep 93 12:27:08 PDT
Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1)
	id AA29970; Wed, 22 Sep 93 12:27:05 PDT
Received: from spdev.East.Sun.COM (spdev-gw.East.Sun.COM) by East.Sun.COM (4.1/SMI-4.1)
	id AA25051; Wed, 22 Sep 93 15:27:03 EDT
Received: by spdev.East.Sun.COM (4.1/6.1-spdev1) id AA17096; Wed, 22 Sep 93 15:26:53 EDT
Date: Wed, 22 Sep 93 15:26:53 EDT
From: "Timothy G. Smith - Special Projects" &lt;tgsmith@sun.com&gt;
Message-Id: &lt;9309221926.AA17096@spdev.East.Sun.COM&gt;
To: cad@BRL.MIL
Subject:  4.0 on Solaris 2.X (and other porting/misc issues)

<p>
Folks,

<p>
I am in the process of getting 4.0 up and running on Solaris 2.3.  I
have a fair amount of stuff already working and am on the way towards
getting the rest of it working and have a couple of questions that
someone out there might be able to answer.

<p>
I am not on the mailing list so if I am asking questions that have
been discussed before (or discussed to death) please kindly refer me
to the archives (if there are any) and excuse my interruption.

<p>
- The code classifies the world into two interface camps (BSD and
SYSV).  While historically this has been a good way to do things the
days of vanilla BSD versus SYSV are waning.  It looks like most
vendors are going to hybrid systems that support a number of
interfaces.  Are there any plans to try adapt to the brave new hybrid
world any time soon?  I am going to have to butcher the code to make a
number of things work properly and am not looking forward to
perpetrating such bogosity if it can be avoided.

<p>
As an aside, I have worked on a couple of projects where we have taken
the approach of using a single OS define to select a the right set of
interfaces to use on a given platform.  It has been my experience that
this really cuts down on the "ifdef soup" in large projects and makes
it fairly quick and painless to port to a new platform.  It would be
great to see the cad source set up like this although it would require
a boat load of work.

<p>
- Is anyone using shared libraries?  I have not really done any memory
profiling yet but shared libraries usually tend to be a win and do not
require too much extra effort.

<p>
- Is there any tentative release data for the next version yet and is
there a working list of what will be in the next release?

<p>
- Is BRL interested in taking back diffs for solaris support and
integrating them into the next release?

<p>
- When I worked at BRL the platform of choice for running the cad
package was from SGI.  I assume this is still true.  Can someone fill
me in on the config and performance numbers of typical SGI being used
for CAD work?  I would like to put together a similarly configured sun
to see how it performs.

<p>
thanks,
--tim

<p>
PS:  Please make sure to include me, tgsmith@sun.com, directly in any
replies since I am not on the cad mailing list.
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa19109; 30 Sep 93 14:23 EDT
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa21622; 30 Sep 93 14:17 EDT
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa21565; 30 Sep 93 14:12 EDT
Received: from cs.ida.org by WHARF.BRL.MIL id aa16485; 30 Sep 93 14:01 EDT
Received: from omni.ida.org by ida.org (4.1/SMI-DDN)
	id AA04385; Thu, 30 Sep 93 14:01:14 EDT
Received: from oed-u1.ida.org by omni.ida.org (4.1/SMI-4.1)
	id AA13674; Thu, 30 Sep 93 14:01:13 EDT
Received: from bturner-pc.ida.org by oed-u1.ida.org (4.1/SMI-4.1)
	id AA22076; Thu, 30 Sep 93 14:01:11 EDT
Date: Wed, 29 Sep 1993 14:00:15
From: Ben Turner &lt;bturner@ida.org&gt;
To: cad@BRL.MIL
Subject: Axes, Automating Repetitive MGED Chores
Message-Id: &lt;QCA9CD30@bturner-pc&gt;

<p>

<p>
Thomas Browder writes:
&gt;
&gt;A great aid in MGED would be a constant XYZ coord. system
&gt;orientation aid, say a small set of labeled unit vectors
&gt;in the lower right corner of the screen.
&gt;

<p>
Axes are not automatically available in MGED but can easily be built
as an added element to a .g database.  "The MGED User's Manual",
Volume IV of the BRL-CAD Release 4.0 Documentation describes building
coordinate axes in Chapter 13.  Once built, the axes may be included
in any output to aid in orientation and to provide scale.

<p>
Repetitive chores like adding coordinate axes, placing multiple copies
of objects into databases (ex. illustrating burst points around a ground
target), or generating a depiction of a shotline given impact coordinates
and final azimuth/elevation can all be all be automated.  Commands from a
file can be redirected or commands from a program can be piped into MGED
avoiding the repetitious interactive input.

<p>
ex:  #mged test.g &lt;build_test.cmd
 or  #build_test &lt;build.dat | mged test.g

<p>
The creator of the file or the program anticipates the needed MGED command
sequence.  MGED opens the database with null display, echoes the prompts the
user would otherwise see and terminates on EOF.

<p>
The following shell and awk files provide a quick kludge to automate
the process of adding a single set of coordinate axes to a .g database
where the user specifies an offset (in model coordinates) and axis size
parameters.  The shell script simplifies parameter passing to awk.  The
awk script generates mged commands which can be piped to mged.  Three
cylinders are generated at the specified intersection, defined as regions,
color coded (rgb &lt;==&gt; xyz) and grouped as __axes.  If needed __axes may
be object edited to a better location or they can be removed with
"killtree __axes" and regenerated with more desirable properties.
A sample of the input generated for MGED is also included.

<p>
- beginning of shell file "gen_axes.sh" -
#!/bin/sh
#shell file to invoke awk program to generate
#  mged commands to build coordinate axes
#  (shell file simplifies parameter passing)
#
#usage:  sh gen_axes.sh x0 y0 z0  length diameter|mged db.g
#  invokes:
#  awk -f gen_axes.awk x0=$1 y0=$2 z0=$3 len=$4 diam=$5
#  where:  x0 y0 z0 define the offset from the origin to place axes
#          length of the cylinders making up the axes and
#          diameter of the cylinders
#          and output is fed to mged to add to db.g
#
#  ex:  sh gen_axes.sh 0 -3000 0 1000 10|mged test.g
#  would generate axes in test.g 1 meter long, 1 cm diameter
#  with an intersection displaced -3 meters in y on the X/Y plane
#
#  brute force (simple hard coding) employed, decorate at leisure
#  solids are named __axes_x.s __axes_y.s __axes_z.s
#  regions are named __axes_x.r __axes_y.r __axes_z.r
#  the group is named __axes
###################################################################
awk -f gen_axes.awk x0=$1 y0=$2 z0=$3 len=$4 diam=$5
- end of shell file "gen_axes.sh" -

<p>

<p>
- beginning of awk file gen_axes.awk -
###################################################################
#awk program to generate mged commands to build coordinate axes
#
#usage:  sh gen_axes.sh x0 y0 z0  length diameter
#  where gen_axes.sh invokes
#  awk -f gen_axes.awk x0=$1 y0=$2 z0=$3 len=$4 diam=$5
#  where:  x0 y0 z0 define the offset from the origin to place axes
#          length of the cylinders making up the axes and
#          diameter of the cylinders
#
#  ex:  sh gen_axes.sh 0 -3000 0 1000 10|mged test.g
#  would generate axes in test.g 1 meter long, 1 cm diameter
#  with an intersection displaced -3 meters in y on the X/Y plane
#
#  brute force (simple hard coding) employed, decorate at leisure
#  solids are named __axes_x.s __axes_y.s __axes_z.s
#  regions are named __axes_x.r __axes_y.r __axes_z.r
#  colors are reddish (x), greenish (y), and bluish (z)
#  the group is named __axes
###################################################################

<p>
END{
radius = diam/2

<p>
printf("regdef 19997\n")  #setup arbitrarily for idents 19997-9

<p>
#  X axis
printf("in __axes_x.s rcc %f %f %f", x0, y0, z0)        #name, rcc, origin
printf("  %f %f %f", len, 0, 0)                         #length along x
printf("  %f\n", radius)                                #radius of rcc
printf("r __axes_x.r u __axes_x.s\n")                   #region def
printf("mater __axes_x.r\nplastic\n\n250 150 150\n\n")  #color

<p>
#  Y axis
printf("in __axes_y.s rcc %f %f %f", x0, y0, z0)
printf("  %f %f %f", 0, len, 0)
printf("  %f\n", radius)
printf("r __axes_y.r u __axes_y.s\n")
printf("mater __axes_y.r\nplastic\n\n150 250 150\n\n")

<p>
#  Z axis
printf("in __axes_z.s rcc %f %f %f", x0, y0, z0)
printf("  %f %f %f", 0, 0, len)
printf("  %f\n", radius)
printf("r __axes_z.r u __axes_z.s\n")
printf("mater __axes_z.r\nplastic\n\n150 150 250\n\n")

<p>
#  group
printf("g __axes __axes_x.r __axes_y.r __axes_z.r\n")

<p>
}
- end of awk file gen_axes.awk -

<p>
- sample of output that would be sent to mged for example given (\ is cont) -
grendel 31% sh gen_axes.sh 0 -3000  0 1000 10
regdef 19997
in __axes_x.s rcc 0.000000 -3000.000000 0.000000  1000.000000 0.000000\
0.000000  5.000000
r __axes_x.r u __axes_x.s
mater __axes_x.r
plastic

<p>
250 150 150

<p>
in __axes_y.s rcc 0.000000 -3000.000000 0.000000  0.000000 1000.000000\
0.000000  5.000000
r __axes_y.r u __axes_y.s
mater __axes_y.r
plastic

<p>
150 250 150

<p>
in __axes_z.s rcc 0.000000 -3000.000000 0.000000  0.000000 0.000000\
1000.000000  5.000000
r __axes_z.r u __axes_z.s
mater __axes_z.r
plastic

<p>
150 150 250

<p>
g __axes __axes_x.r __axes_y.r __axes_z.r
- end of sample output -

<p>

<p>
-----------------------------------------------------------------------
Dr. Benjamin W. Turner                                  bturner@ida.org
Operational Evaluation Division                 Office:  (703) 845-6931
Institute for Defense Analyses                 Autovon:        289-1980
1801 N. Beauregard Street                          FAX:  (703) 845-6911
Alexandria, VA 22311-1772                       Verify:  (703) 845-2544
-----------------------------------------------------------------------

<p>
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa25758; 17 Nov 93 12:04 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa20898; 17 Nov 93 11:01 EST
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa20700; 17 Nov 93 10:49 EST
Received: from relay1.UU.NET by WHARF.BRL.MIL id aa08850; 17 Nov 93 10:31 EST
Received: from bruker.com (via bii.BRUKER.COM) by relay1.UU.NET with SMTP
	(5.61/UUNET-internet-primary) id AA14781; Wed, 17 Nov 93 10:32:48 -0500
Received: by bruker.com (4.1/SMI-4.1)
	id AA00425; Wed, 17 Nov 93 10:28:45 EST
From: joe edward meier &lt;jem@bruker.com&gt;
Message-Id: &lt;9311171528.AA00425@bruker.com&gt;
Subject: Problems dublicating Animation tutorial
To: BRL-MIL &lt;CAD@BRL.MIL&gt;
Date: Wed, 17 Nov 93 10:28:45 EST
X-Mailer: ELM [version 2.3 PL0]

<p>
I was trying to duplicate the things in the "Animation Techniques in
BRL-CAD" WWEB file.  Most everything went fine except when I tried
to preview the animation script in "mged", in which case "mged" just
quit on me when I typed the command "preview moss.rtanim".  This
happend in both the 4.1 and 4.2 version of BRL-CAD.  Below is the
output from meged:

<p>

<p>
50 jake/fj/jem_files/brl-cad4.2/db&gt; mged moss.g
BRL-CAD Release 4.2   Graphics Editor (MGED)
    Tue Nov 16 13:25:19 EST 1993, Compilation 18
    jem@crim1:/disk4/jem_files/brl-cad4.2/mged

<p>
attach (nu|tek|tek4109|ps|plot|sgi|X)[nu]? sgi
ATTACHING sgi (SGI 4d)
Gary Moss's "World on a Platter" (units=mm)
mged&gt;preview moss.rtanim
eyepoint at (0,0,1) viewspace
rt_do_cmd(orientation):  command not found
command failed: orientation
mat_inv:  error! fabs(y)=0
MATRIX singular matrix:
      0.000    0.000    0.000    0.000
      0.000    0.000    0.000    0.000
      0.000    0.000    0.000    0.000
      0.000    0.000    0.000  200.000

<p>
mat_inv: singular matrix

<p>

<p>
The "moss.rtanim" script seems fine to me, because it works fine
when I create the Postage stamp animations.  Does any one know why
this is not working? I am running on a 4D/35 with Irix 4.0.5.

<p>
  I also have a few more questions.  The first is how the mpeg movie
for the animations in this paper were created? Is there some public
domain software which can convert the BRL-CAD pix files into a MPEG
file?  Finally, whay are the main new features of the 4.2 version.  Is
it just a improved X11 version of "mged"?  I could sure use the NURB
editting capability that is being worked on.  Any plans on a beta
relase of this stuff?

<p>
Thanks,

<p>
Joe
--
<hr>
    Joseph Meier, Ph.D.
    Senior NMR Software Scientist

<p>
    Bruker Instruments Inc. USA
    Billerica, MA. 01821

<p>
    Phone: 508-667-9580
    Fax:   508-663-9177

<p>
    jem@bii.bruker.com		Internet
    !{uunet,ulowell}!bii!jem	UUCP
<hr>
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa09408; 22 Nov 93 17:21 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa04043; 22 Nov 93 16:15 EST
Received: from admii.arl.army.mil by WALRUS.BRL.MIL id aa03947;
          22 Nov 93 16:11 EST
Date:     Mon, 22 Nov 93 15:58:02 EST
From:     Glenn Gillis &lt;gillis@BRL.MIL&gt;
To:       cad@BRL.MIL
Subject:  SURVIAC BRL-CAD User's Group Meeting, 29 September 1993
Message-ID:  &lt;9311221558.aa11901@ADMII.ARL.ARMY.MIL&gt;

<p>

<p>
Attendees:

<p>
   Jeff Foulk         SURVIAC ASO                   (410) 273-7794
   Carla Moyer        SURVIAC ASO                   (410) 273-7794
   Bob Strausser      SURVIAC ASO                   (410) 273-7794
   Jack Benkert       SURVIAC BA&H                  (703) 280-8239
   Ed Hathaway        SURVIAC BA&H                  (703) 902-5829
   Carl Hutzler       SURVIAC BA&H                  (703) 902-5830
   Dr. Paul Dietz     ARL                           (410) 278-6282
   Bill Mermagen, Jr. ARL                           (410) 278-8740
   Joseph Silverstein ARL                           (301) 394-3170
   Kellye C. Frew     Applied Research Associates   (505) 883-3636
   Chris Johnson      Geometric Solutions Inc.      (410) 273-7058
   George Anderson    IDA                           (703) 845-2539
   Ben Turner         IDA                           (703) 845-6931
   Carole Keyser      Ketron                        (410) 583-8386
   Steve McKay        Pacific-Sierra Research Corp. (703) 516-0235
   Bud Bruenning      Sverdrup Technology           (904) 729-6497

<p>
The SURVIAC BRL-CAD User's Group Meeting was held at the Booz-
Allen Hamilton facilities in McLean, Virginia.  Mr. Jeff Foulk,
SURVIAC Aberdeen Satellite Office (ASO) project manager, welcomed
the attendees, presented the purpose of the meeting, and provided
an overview of the SURVIAC organization.  The thrust of the
meeting was presentation of uses for BRL-CAD, program updates, and
discussion of user problems and ideas.

<p>
Ms. Carla Moyer, SURVIAC ASO administrative manager, presented the
function of the SURVIAC ASO regarding BRL-CAD.  SURVIAC full
support includes distributing the BRL-CAD source code and
documentation, providing telephone support for installation and
operation technical inquiries, distributing maintenance release
updates, and maintaining a mailing list database of users.  Points
of contact for BRL-CAD 4.0 are no longer relevant.

Mr. Bob Strausser, SURVIAC ASO BRL-CAD technical POC, presented an
overview of technical inquiries over the last 9 months.  Inquiries
were primarily administrative (67%) with the balance divided
between installation and operation questions.

<p>
During the Technical Inquiry overview, Dr. Dietz stressed that the
vdeck conversion program and gift shotlining program are obsolete.
The principal problem with using vdeck lies with the expansion of
BRL-CAD primitives beyond the supported primitives of the old
comgeom format (generated by vdeck).  This can result in the loss
of data by the conversion back into the comgeom era.  Joseph
Silverstein is using vdeck and gift to interface between BRL-CAD
geometries and the schrim radar signature program.  Dr. Deitz and
Bill Mermagen, Jr. recommended using rtrayhist and xpatch as
better tools than the gift / schrim pair.  The vdeck and gift
programs are also used to feed hevart because the sequence of
shotlines provided by rtg3 is not compatible with hevart's input
requirements.  Carole Keyser recommended using shotb2g, it
converts rtg3 output into a format compatible with hevart.
Contact John Anderson at ARL (278-7267) for copies of the shotb2g
program.

<p>
Mr. Bob Strausser also presented a status update on the patch-g
conversion program.  This program provides initial conversion of
FASTGEN faceted geometry descriptions into BRL-CAD format.  The
updated program has been sent to Bill Mermagen, Jr. for review and
release.

<p>
Bill Mermagen, Jr. presented an overview of BRL-CAD status and
plans.  The next release of BRL-CAD anticipated Summer 1994, will
have a production version of the N-manifold Geometry (NMG)
capability.  This will permit use of polygonal representations for
import, export, and visualization and will provide better support
for faceted-geometry dependent analysis codes.  Along with the
NMGs, new primitives (i.e.. elliptical tori, paraboloids, and
hyperboloids) will be available.  A second task area has been
revising the MGED graphical user interface (GUI) to make the
system more user friendly.  Two GUIs are in development as
replacements for the current interface.  One GUI (being developed
by Phil Dykstra) is based on MOTIFF and X-windows.  The other GUI
(being developed by Mike Muuss) is
vendor independent (depart from X-window dependency).  The BRL-CAD
team (primarily Mike Muuss) is also examining the possibility of
using virtual reality.  The third task area has provided more
conversion routines for importing foreign CAD geometries into BRL-
CAD.

<p>
The importance of BRL-CAD's need to support faceted geometries
(the NMG / tessellation upgrade)  was reinforced by Kellye Frew ,
Applied Research Associates (ARA).  She indicated that ARA is
involved with an effort to generate a 3-D mesh to interface with
epic.  BRL-CAD was used for Phase I of this program.

<p>
Mr. Bud Bruenning, Sverdrup Technology, presented an overview of
how he is using BRL-CAD and enhancements he would like to see.
The highest priority was a simple tutorial document.  He would
also like some new image generation capabilities (cross sectional
cuts, automated component id number labeling, easier overlays).
Lesser issues concerned improvements to patch-g and better support
from the developers.  Dr. Dietz suggested that Bud visit with ARL
for a "working group" session on generating images and plots.  Any
one interested in participating in an imaging working group,
please contact the SURVIAC ASO (Resalee Bilka).

<p>
Geometric Solutions, Inc. (GSI) presented a report on the addition
of joint information to BRL-CAD models.  This new ability, as
outlined by Chris Johnson, GSI, will allow users to change the
configuration of targets with a simple click and drag interface.

<p>
This new capability is being integrated with BRL-CAD and will be
available to all in the next BRL-CAD release.  More information is
available from Victor Cericole, Jr., GSI Software Director, 1-800-
598-BRLCAD (2752).

<p>
Mr. Steve McKay, Pacific-Sierra Research Corp., expressed an
interest in accessing a model description database.  He is aware
of several and was wondering if any coordination existed between
these databases.  Information concerning geometry model databases
would be appreciated as the SURVIAC ASO researches this issue.

<p>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

<p>
Prepared by Bob Strausser, SURVIAC Aberdeen Satellite Office, (410) 273-7794.

<p>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


<p>
<hr>
<hr>
Date:     Wed, 22 Dec 93 7:07:30 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
To:       Jim Hunt &lt;jehunt@brl.mil&gt;
cc:       acst@BRL.MIL, Jill@BRL.MIL, PHD@BRL.MIL
Subject:  Re: rt_free( rt_i ) ???
Message-ID:  &lt;9312220707.aa28241@WOLF.BRL.MIL&gt;

<p>

<p>
&gt; BTW, I had been using rt_malloc, [...]

<p>
Good, I'm glad it has been useful.

<p>
&gt; Now, I have another question.  The interactive program I am developing
&gt; may import many different BRL-CAD data bases during a single session.
&gt; Each may optionally be raytraced any number of times.  When I am done
&gt; each raytrace, I am finished with the struct rt_i that rt_dirbuild
&gt; gave me.  Is there a (kosher) way to free the memory allocated for this
&gt; rt_i and its members?

<p>
The answer is: YES.  I already thought of that. :-)  It's broken out
in several pieces, so you can free different parts at different times.

<p>
	/* Release dynamic storage */
	rt_vlist_cleanup();		/* if you use vlist */

<p>
	rt_clean( rtip );		/* eliminate prepping, but not db */
	db_close( rtip-&gt;rti_dbip );	/* eliminate all db info */

<p>
#if MEMORY_LEAK_CHECKING
	rt_prmem("After complete processing");
#endif

<p>
I noticed that there was no way to dispose of the rt_i structure itself,
so I've added:

<p>
	rt_free_rti( rtip );		/* does rt_clean, db_close, rt_free */

<p>
Also note that if you are not changing the database, and not doing any
articulations, you can just keep using the existing rt_i structure.
No need to re-prep.

<p>
If you are doing articulations, you can rt_clean(), change articulation,
and then just call rt_gettrees() and rt_prep().

<p>
If you are going to be changing databases in mid-stream, there is
probably some additional minor library support that you will need.
(Such as routines like rt_new_rti(), and perhaps reference counts
on the db_i structures).  I have always intended for this to be
possible, but I've never actually tried it, so you know what that means.
Please let me know what you have in mind, so we can support it.

<p>
&gt; I'm already peeking (poking) at struct region
&gt; to put criticality information in the reg_udata member.  Is that even
&gt; kosher?

<p>
reg_mfuncs and reg_udata are pointers for you to set as you need.
It's entirely kosher for you to make them point at your own data
structures.  (Just don't serve them on the same plates as the Swiss
cheese.)

<p>
&gt; Maybe I should make a (short) list of the rules I am breaking
&gt; (especially w.r.t. union record) and see if you guys can come up with
&gt; an alternative for me (either a better way for me to do it, or new
&gt; library calls to be maintained outside of application code.)

<p>
That sounds like a very good idea.  If there is some operation that you
need to be able to do to the data structures, probably somebody else
will have a similar need in the future.  So it would be best to minimize
special LIBRT interface code built into your application.   Unless it
turns out to be really hard, I'd rather just make sure that the library
gives you all the support that you need.  So speak up. :-)

<p>
So, now I'm curious:  what are you doing to "union record"?  That
structure defines the on-disk database format, and is _the_ most
difficult to change....  Hopefully you meant "union region"?

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa21595; 11 Jan 94 17:32 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa27960; 11 Jan 94 16:44 EST
Received: from admii.arl.army.mil by WALRUS.BRL.MIL id aa27908;
          11 Jan 94 16:41 EST
Date:     Tue, 11 Jan 94 16:39:06 EST
From:     Glenn Gillis &lt;gillis@BRL.MIL&gt;
To:       akekesi@nvl.army.mil
cc:       cad@BRL.MIL
Subject:  RE: BRL-CAD newsletter
Message-ID:  &lt;9401111639.aa23469@ADMII.ARL.ARMY.MIL&gt;

<p>
In response to:

<p>
&gt;Date: Mon, 3 Jan 94 09:04 EST
&gt;From: Alex Kekesi &lt;akekesi@nvl.army.mil&gt;
&gt;Subject: BRL-CAD newsletter
&gt;
&gt;Hi,
&gt;
&gt;   I understand there is an e-mail newsletter for BRL-CAD
&gt;users.  I would be very interested in joining if such a
&gt;newsletter exists.
&gt;
&gt;Thanks in Advance!
&gt;
&gt;B.A. Kekesi
&gt;

<p>
Alex,

<p>
The SURVIAC ASO is currently providing a BRL-CAD newsletter
for both SURVIAC and FTP registered users of BRL-CAD.  It is
published quarterly and mailed to the users.  The December
issue was mailed last week.  If you do not receive it
shortly, forward your name and address to me for addition to
the mailing list(or I can e-mail it to you).

<p>
The newsletter was originally intended as an extension to
this e-mail forum, providing announcements of events and
extracts from the e-mail for non-E-mail users.  All
contributions and / or suggestions for topics of discussion
are welcome.

<p>

<p>
Bob Strausser
SURVIAC ASO Technical Rep

<p>

<p>
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa13822; 28 Jan 94 11:22 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa10915; 28 Jan 94 10:22 EST
Received: from worm.brl.mil by WALRUS.BRL.MIL id aa10621; 28 Jan 94 10:11 EST
Date:     Fri, 28 Jan 94 10:06:33 EST
From:     "Jill H. Smith, Ch., Vuln. Meth. Br." &lt;jill@BRL.MIL&gt;
To:       jim montgomery &lt;monty@mensa.usc.edu&gt;
cc:       cad@BRL.MIL
Subject:  Re:  BRL-CAD classes
Message-ID:  &lt;9401281006.aa14687@WORM.BRL.MIL&gt;

<p>
Jim,

<p>
ARL is not currently sponsoring courses on BRL-CAD, however, there are at
least two commercial vendors in our area that offer BRL-CAD training:

<p>
Geometric Solutions Inc.
100 Custis St.
Aberdeen, MD  21001
(410) 273-7058

<p>
Survice Engineering Co.
1003 Old Phila. Rd.
Aberdeen, MD  21001
(410) 273-7722

<p>
Hope this helps.

<p>
Jill Smith
Chief
Vulnerability Methodology Br.
ARL
<hr>
<hr>
Received: from worm.brl.mil by WOLF.BRL.MIL id aa02107; 25 Jan 94 19:28 EST
Date:     Tue, 25 Jan 94 19:25:24 EST
From:     "Jill H. Smith, Ch., Vuln. Meth. Br." &lt;jill@BRL.MIL&gt;
To:       mdelapp@mcl.bdm.com
cc:       mike@BRL.MIL, stay@BRL.MIL, jra@BRL.MIL, phd@BRL.MIL
Subject:  BRL-CAD as Interim PDES/STEP standard
Message-ID:  &lt;9401251925.aa04336@WORM.BRL.MIL&gt;

<p>
To mdelapp,

<p>
BRL-CAD has been proposed as an AMC standard for geometric system data
exchange through the AMC Functional Coordinating Group for Computer
Interoperability and Interchange (FCG-CII).  PDES/STEP are ultimately tackling
a much broader spectrum of data, such as plumbing and sheet-metal-folding
data, than what BRL-CAD represents.  BRL-CAD however offers an OPEN (i.e.
government owned) format for exchange of geometric information and
associated properties at a level of information sufficient for most of the
engineering analyses performed within AMC.  No commercial CAD/CAE package can
meet all the requirements for geometry representation/interrogation to meet
the analysis needs of this community - hence the proliferation of different
CAD/CAE systems.

<p>
BACKGROUND.  The issue of geometric target data exchange came up between ARL
(old BRL), ARDEC, Benet and TACOM when it was pointed out that each
organization used a different modeling system.  For efficient design,
evaluation and integration of Army systems it would be of benefit if these
organizations could exchange system information in electronic format.
MICOM also asked to be included on the Technical Working Group to address
these issues, since within MICOM they had as many or more
different/non-compatible modeling systems as the rest of us put together.
Most of the commercial modeling systems have proprietary data
representations and although you can build geometric target descriptions in
these modelers and perform various analyses, most do not allow you to export
the geometry and associated information such as material properties.
Additionally, the underlying mathematical representations of the data, if
available, may not be compatible. That is, a format for exchange does not
handle translation of data from one mathematical form to another.

<p>

<p>
CURRENT STATUS. PDES/STEP addresses only the problem of exchange, not
translation.  That is, if two modeling systems represent the geometric
information in the same mathematical form - say splines, then PDES/STEP
specifies the format for exchange. However, the PDES/STEP standardization
effort is still fairly young and not all geometric entities are yet
specified for exchange. For example, in the area of solids, there is no
specification for the exchange of a truncated general cone, elliptical torus,
paraboloid of one sheet, etc.

<p>
Within AMC we have both problems, that is, the underlying mathematical
representations of the geometry are not the same and not all geometric
representations are covered by exchange specifications.  BRL-CAD, used by
ARL, is a Constructive Solid Geometric modeling system with Boolean trees.
Intergraph, used by TACOM, is believed to be a spline-based system, although
the specific data representations are proprietary.  Translators, which may
be approximations, must be developed to transfer data between these systems.

<p>

<p>
TRANSLATORS

<p>
BRL-CAD &lt;=&gt; Intergraph.  The Foreign Science and Technology Center and the
Tank Automotive Command jointly sponsored BRL-CAD &lt;=&gt; Intergraph translators
through a contract with Intergraph. The Intergraph =&gt; BRL-CAD translation is
accomplished by converting GIFT (Geometric Information For Targets) and
Booleans into the corresponding BRL-CAD representations.  Any solid not
represented in the GIFT format is tessellated and transferred as a
polysolid.  The Intergraph =&gt; BRL-CAD translator works reasonably well,
when Intergraph models have been constructed following certain stylistic
rules peculiar to the translator, however the BRL-CAD=&gt; Intergraph
translator has a much greater loss of information.

<p>
PATCH-G.  The patch-g translator was developed by BRL (now ARL) under
sponsorship by the Air Force.  Patch-g translates FASTGEN2/FASTGEN3 target
descriptions into BRL-CAD .g format.  Plate-mode facets are difficult to
convert.

<p>
Jack-G.  Jack is an articulated human figure package developed by the
University of Pennsylvania under the sponsorship of the Human Engineering
Laboratory (now Human Research & Engineering Directorate, Army Research
Laboratory).  ARL/SLAD developed the jack-g translator to import articulated
human figures into vehicles.

<p>
ACAD &lt;=&gt; BRL-CAD.  ACAD is the geometric modeling system developed by
General Dynamics in the Fort Worth office (this branch has since been sold
to one of the aircraft companies). ACAD has developed and distributes the
ACAD &lt;=&gt; BRL-CAD translators.  ARL has no experience with the use of these
translators.

<p>
BRL-CAD &lt;=&gt; Euclid.  Euclid is a geometric modeling system developed by
Matra Datavision of France.  The underlying data representation is believed
to be cubic Bezier patches (the simplest subset of B-splines), however,
the users with whom we are coordinating the effort, have access to only a
polygonal boundary representation of their geometry. ARL is currently
extending our valid data representations to include N-Manifold Geometry
(NMG) data structures.  In the initial implementation, NMGs will include
polygonal boundary representations and the associated topological
information.  We are currently able to import Euclid polygons into BRL-CAD
and view them using the polygon fill hardware of the SGI, but cannot
interrogate (i.e., raytrace) the geometry.  Conversion routines for CSG to
NMG forms must be completed to export BRL-CAD to Euclid.

<p>
BRL-CAD &lt;=&gt; IGES.  The IGES=&gt; BRL-CAD converter has been developed in-house
(by ARL) and has recently been upgraded to include the IGES BREP (boundary
representation) objects into N-Manifold Geometry (NMG) data structures for
planar faces and IGES drawings (2D lines) to BRL-CAD NMG's.  The iges-g
converter translates IGES Constructive Solid Geometry (CSG) files into
BRL-CAD CSG files with approximations for IGES solids of revolution and
solids of linear extrusion.  The g-iges translator allows for two types of
IGES output from BRL-CAD.  1) A 100% facetized representation can be
selected where each region is facetized to an NMG object before output as an
IGES "Manifold Solid BREP Object (MSBO)", or 2) a mostly CSG file can be
produced where each region is output as an IGES "Boolean Tree" entity and
each solid is output as the corresponding IGES solid.  In cases where there
is no corresponding IGES solid (truncated general cone, elliptical torus,
etc.), a facetized approximation of the BRL-CAD solid is output as an IGES
MSBO.  The efforts described here depend on the current NMG work mentioned
in the previous paragraph.  We expect the NMG work and translators to be
available in the next BRL-CAD release.

<p>
Target descriptions in BRL-CAD format are a deliverable from the contractor
on most ground system development programs.  Since the BRL-CAD format
is government developed and open, it can be specified as a deliverable in a
contract.  This facilitates the transfer to Intergraph for analyses by TACOM
and directly feeds the vulnerability/lethality analyses required by ARL.

<p>
The Intelligence Community Modeling Group is also relying on BRL-CAD
geometry both as input to various signature codes (e.g. Xpatch, TSAR) and
also as an intermediate file format for exchange.  We are currently
investigating extending our geometry representations to include a "height
field" data type to facilitate terrain modeling in support of a DMSO
proposal for signature generation and automatic target recognition.

<p>
I have included below a note from one of our users who uses BRL-CAD
specifically as an interface between other CAD tools.

<p>
<hr> <hr>
Received: from wharf.brl.mil by WORM.BRL.MIL id aa05299; 5 Jan 94 12:18 EST
Received: from VARMIT.MDC.COM by WHARF.BRL.MIL id aa06915; 5 Jan 94 12:18 EST
Received: from huston.mdc.com by varmit (4.1/SMI-4.1)
	id AA05709; Wed, 5 Jan 94 09:12:39 PST
Message-Id: &lt;Chameleon.940105092059.huston@huston.mdc.com&gt;
Date: Wed,  5 Jan 94 09:16:56 PST
Reply-To: Stu Huston &lt;huston@huston.mdc.com&gt;
From: Stu Huston &lt;huston@huston.mdc.com&gt;
To: "Jill H. Smith, Ch., Vuln. Meth. Br." &lt;jill@BRL.MIL&gt;
Subject: RE:  Dual Use

<p>
At Mcdonnell Douglas, we are using BRL-CAD as an interface between other CAD
tools (such as Unigraphics, PATRAN, and SMART) and radiation transport codes to
calculate the radiation dose in space (e.g., from solar flare protons or cosmic
ray heavy ions).  The ray tracing capabilities of BRL-CAD are what led us to
this configuration.  As we gain experience with the package, we may use it as
more of a total integrated product development tool (e.g., for determining mass
properties, etc.).  So far, we are very pleased with tho package.

<p>
Future uses for the radiation transport work include medical imaging and
therapy, and risk calculations for the High-Speed Civil Transport.

<p>
--------------------------------------------------------
Stuart L. Huston
McDonnell Douglas Aerospace
5301 Bolsa Ave. M/S 13-3
Huntington Beach, Calif.  92647
phone (714) 896-4787
fax   (714) 896-6930
--------------------------------------------------------
huston@huston.mdc.com

<p>
<hr> <hr>

<p>
If you have questions or require more information, please feel free to
contact me.

<p>
Jill H. Smith
Chief
Vulnerability Methodology Branch
(jill@arl.army.mil)
410-278-6644
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa07794; 24 Jan 94 11:03 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa20254; 24 Jan 94 10:14 EST
Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa20083; 24 Jan 94 10:09 EST
Received: from relay1.UU.NET by WHARF.BRL.MIL id aa20886; 24 Jan 94 10:04 EST
Received: from bruker.com (via bii.BRUKER.COM) by relay1.UU.NET with SMTP
	(5.61/UUNET-internet-primary) id AAwaga08346; Mon, 24 Jan 94 10:01:01 -0500
Received: by bruker.com (4.1/SMI-4.1)
	id AA21660; Mon, 24 Jan 94 09:55:31 EST
From: joe edward meier &lt;jem@bruker.com&gt;
Message-Id: &lt;9401241455.AA21660@bruker.com&gt;
Subject: proc-db/pipetest.c questions
To: BRL-MIL &lt;CAD@BRL.MIL&gt;
Date: Mon, 24 Jan 94 9:55:30 EST
X-Mailer: ELM [version 2.3 PL0]

<p>
I was trying to figure out how to use the pipe generating code, by
playing around with pipetest.c, but it seems like all the pipes are
generated with a infinitly small diameter.  Even, if I try to change
the id and od parameters.  The pipes that are generated by the program
cannot be zoomed in on.  How do I increase the diameters of the pipes?
I tried using the following for:
        {
                {(long)WDB_PIPESEG_MAGIC, 0, 0},
                0, 1, 0,
                0, 0, 0,
                500.10, 900.5, WDB_PIPESEG_TYPE_LINEAR
        },
From my understanding this should give an id=500.10 mm and an od=900.5,
but I still cannot zoom in on the resulting pipe.

<p>
Also, how does one specify bends greater than 90 degrees (like say
180 degreees)?

<p>

<p>
--
<hr>
    Joseph Meier, Ph.D.
    Senior NMR Software Scientist

<p>
    Bruker Instruments Inc. USA
    Billerica, MA. 01821

<p>
    Phone: 508-667-9580
    Fax:   508-663-9177

<p>
    jem@bii.bruker.com		Internet
    !{uunet,ulowell}!bii!jem	UUCP
<hr>
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa19076; 28 Jan 94 20:30 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa22450; 28 Jan 94 19:38 EST
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa22448; 28 Jan 94 19:34 EST
Date:     Fri, 28 Jan 94 19:26:08 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       joe edward meier &lt;jem@bruker.com&gt;
cc:       BRL-MIL &lt;CAD@BRL.MIL&gt;
Subject:  Re: proc-db/pipetest.c questions
Message-ID:  &lt;9401281926.aa18007@WOLF.BRL.MIL&gt;

<p>

<p>
Joseph Meier wrote -

<p>
&gt; I was trying to figure out how to use the pipe generating code, by
&gt; playing around with pipetest.c, but it seems like all the pipes are
&gt; generated with a infinitly small diameter.

<p>
The old Television saying applies here: "The Problem is Not in Your Set".

<p>
The support for PIPE solids is very rudimentary.  What you see was done
as part of the proposal for a joint project with Air Systems Branch that
was not funded.   The data structures are defined, and the import/export
routines exist, but the PIPEs can not be ray-traced.  They can't really
be edited in MGED either, and when drawn, only the centerline is
displayed.

<p>
So, what you are seeing is not that the diameter is not being stored in
the database, but instead that the drawing routine is not drawing the
exterior of the pipes.

<p>
It is unlikely that anyone in ARL will be fleshing out the PIPE solid,
at least not within this FY. If you wish to complete the code yourself,
the changes are restricted to one file:  librt/g_pipe.c.  In the
alternative, you might be able to use cylingders and spheres, as is
often done now.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa20681; 28 Jan 94 23:54 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa22879; 28 Jan 94 23:04 EST
Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa22870; 28 Jan 94 22:54 EST
Date:     Fri, 28 Jan 94 22:48:33 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  Irix 5 GL // LIBFB bug
Message-ID:  &lt;9401282248.aa19808@WOLF.BRL.MIL&gt;

<p>

<p>
Those of you with Silicon Graphics machines running recent versions
of the operating system (Irix 5) have probably noticed how programs
linked with -lgl (most notably all the BRL-CAD programs that use LIBFB)
won't work unless $DISPLAY is pointing to a GL-capable workstation.

<p>
Well, in the release notes for Irix 5.2, they make mention of this:

<p>
      You can work around this in one of two easy ways:

<p>
              1.  Set your DISPLAY environment variable to a GL-
                  capable system.

<p>
              2.  Set an environment variable called
                  __SGI_NO_REMOTE_GL before executing the program.
                  This prevents you from rendering remotely should
                  you try to do so. The DISPLAY environment
                  variable is always interpreted as rendering to
                  local host.

<p>
I've added a reminder to my .login file:

<p>
# SGI Irix 5 bug workaround
# setenv __SGI_NO_REMOTE_GL 1

<p>
This isn't something to set all the time, because there are occasions
when using remote GL windows *is* what you intend to do.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa14472; 31 Jan 94 18:45 EST
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa28290; 31 Jan 94 18:34 EST
Received: from admii.arl.army.mil by WALRUS.BRL.MIL id aa28281;
          31 Jan 94 18:32 EST
Date:     Mon, 31 Jan 94 18:29:55 EST
From:     Phil Dykstra (ACISD/ACD) &lt;phil@BRL.MIL&gt;
To:       browder jr &lt;browder@use1.eglin.af.mil&gt;
cc:       cad@BRL.MIL
Subject:  Re:  transformations
Message-ID:  &lt;9401311829.aa16439@ADMII.ARL.ARMY.MIL&gt;

<p>
In the cad distribution, see "doc/anim.txt" and "doc/matrix.txt"
for a short discussion of BRL-CAD matricies and how to use them
in animation.

<p>
Also, see the online paper on "Animation Techniques in BRL-CAD"
via Mosaic at

<p>
	http://www.arl.army.mil/reports/tr-313/index.html

<p>
- Phil
<hr>
<hr>
Received: from whim.brl.mil by WOLF.BRL.MIL id aa00935; 10 Feb 94 6:59 EST
Date:     Thu, 10 Feb 94 6:56:50 EST
From:     Jim Hunt &lt;jehunt@BRL.MIL&gt;
To:       cmoore@BRL.MIL
cc:       acst@BRL.MIL, jehunt@BRL.MIL
Subject:  [Carl Moore:  edpix error messages]
Message-ID:  &lt;9402100656.aa02191@WHIM.BRL.MIL&gt;

<p>
This occurs when you run across the network--running edpix on another machine
using your workstation as the window server.  It wasn't designed to do this
and couldn't under Irix 3.3.  Now, Irix 4+ permits this using X, but it is far
from a smooth interface.  I recommend only running on your local workstation.

<p>
--jim

<p>
PS; thanks for the fixxes to the man page :)

<p>
----- Forwarded message # 1:

<p>
Received: from wolf16.brl.mil by WHIM.BRL.MIL id aa03549; 8 Feb 94 16:51 EST
Received: from wumpus.brl.mil by WOLF.BRL.MIL id aa22008; 8 Feb 94 13:34 EST
Date:     Tue, 8 Feb 94 13:33:47 EST
From:     Carl Moore &lt;cmoore@BRL.MIL&gt;
To:       acst@BRL.MIL
Subject:  edpix error messages
Message-ID:  &lt;9402081333.aa13049@WUMPUS.BRL.MIL&gt;
Resent-Date:  Tue, 8 Feb 94 16:48:27 EST
Resent-From:  	 Mike Muuss &lt;mike@BRL.MIL&gt;
Resent-To:  jehunt@BRL.MIL

<p>
For test purposes, I did an "edpix" run consisting only of
"edpix -f filename.pix" and then immediately exiting.  What
would cause a slew of messages "dgl error (pup): too many callbacks"
to appear?  (I noticed those messages after leaving edpix.)
Would you like to look at the file with that problem?  It seems to
behave normally otherwise.  Let me know and I can supply a path to
that file.

<p>
----- End of forwarded messages
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa29681; 16 Feb 94 23:01 EST
Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id aa08515;
          16 Feb 94 22:54 EST
Received: from wolf16.brl.mil by WALRUS.ARL.ARMY.MIL id aa08380;
          16 Feb 94 22:48 EST
Date:     Wed, 16 Feb 94 22:46:46 EST
From:     Mike Muuss &lt;mike@brl.mil&gt;
To:       CAD@brl.mil
Subject:  pixmatte fix for -w1
Message-ID:  &lt;9402162246.aa29433@WOLF.BRL.MIL&gt;

<p>

<p>
Several people noted that the "pixmatte -w1" alternative that I added to
Lee's EBM paper didn't work.  Programmer's plus-or-minus one problem
bites again.  Here is the fix, in "diff -c" format, suitable for use
with PATCH.

<p>
	Best,
	 -Mike

<p>
*** /usr/tmp/,RCSt1a29429	Wed Feb 16 22:44:01 1994
--- pixmatte.c	Wed Feb 16 22:43:18 1994
***************
*** 171,178 ****
  			break;
  		case 'w':
  			c = atoi(optarg);
! 			if( c &gt; 1 && c &lt; sizeof(pconst) )
  				width = c;
  			break;
  		default:		/* '?' */
  			usage("unknown option\n", 1);
--- 171,180 ----
  			break;
  		case 'w':
  			c = atoi(optarg);
! 			if( c &gt;= 1 && c &lt; sizeof(pconst) )
  				width = c;
+ 			else
+ 				usage("Illegal width specified\n", 1);
  			break;
  		default:		/* '?' */
  			usage("unknown option\n", 1);
***************
*** 349,355 ****
  			exit(1);
  		}
  	}
! 	fprintf( stderr, "pixmatte: %d element comparisons true, %d false\n",
! 		true_cnt, false_cnt );
  	return(0);
  }
--- 351,357 ----
  			exit(1);
  		}
  	}
! 	fprintf( stderr, "pixmatte: %d element comparisons true, %d false (width=%d)\n",
! 		true_cnt, false_cnt, width );
  	return(0);
  }
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa14268; 17 Feb 94 14:04 EST
Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id aa24995;
          17 Feb 94 13:15 EST
Received: from wharf.brl.mil by WALRUS.ARL.ARMY.MIL id aa24821;
          17 Feb 94 13:08 EST
Date:     Thu, 17 Feb 94 12:49:26 EST
From:     "Harry Reed Jr." (GSI|phd) &lt;reed@brl.mil&gt;
To:       batman@nvl.army.mil
cc:       cad@brl.mil
Subject:  Number of solids in the GSI T62A Tank
Message-ID:  &lt;9402171249.aa25291@WHARF.BRL.MIL&gt;

<p>

<p>
Dear John,

<p>
	The target description in question contains 16,000 solids, regions, and
groups.  We can reduce this amount if we remove the slotted screws holding
down the cupolas and reducing the number of solids per link well below 39.

<p>
	Please note that the description is only an exterior description.
Adding the interior will probably increase it by another 12,000.  Thanks.

<p>
	By the way, the target contains battle damage such as dents, third
country effects (non-standard detail items), and test repair items such as
surrogate storage boxes.

<p>
Thanks,
Harry Reed
Geometric Solutions, INC
1-800-598-BRLCad (2752)
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.BRL.MIL id aa10611; 3 Mar 94 18:46 EST
Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id aa16862;
          3 Mar 94 18:06 EST
Received: from waffle.brl.mil by WALRUS.ARL.ARMY.MIL id aa16844;
          3 Mar 94 17:59 EST
Date:     Thu, 3 Mar 94 17:55:06 EST
From:     Paul Stay &lt;stay@brl.mil&gt;
To:       cad@brl.mil
Subject:  Images and Geometry Wanted
Message-ID:  &lt;9403031755.aa02691@WAFFLE.BRL.MIL&gt;

<p>

<p>
BRLCAD users-

<p>
We are looking for images and geometry showing dual-use technology
with BRL-CAD. Dual Use Technology is technology that is of use to the
Defense Department and to other organizations for non-defense
applications. We are looking for BRL-CAD images and or geometry that
show a non-defense application in any one of these areas:

<p>
	    Computer Aided Design (CAD)
	    Computer Aided Manufacturing (CAM)
	    Animation
	    Visualization
	    Image Processing
	    Graphic Arts
	    Architectural Design
	    Education
	    Medical Technology
	    Other (please elaborate)

<p>
All of the images and or geometry will be properly credited, and will
not be distributed or displayed the to the general public unless you
state otherwise. We will use these to help defend our budget and to show
how BRL-CAD is being used by a large and diverse community. We may also
want to use them for a brochure announcing a future BRL-CAD users
conference (Spring of 1995). If you have further questions, or would
like to contribute, please send me e-mail (stay@arl.army.mil).  I can
take images and or geometry from the network, or you can send them to me
via regular postal mail. Let me know and we can work out the details.

<p>
Thanks,
	Paul Stay

<p>

<p>
p.s. I am unable to compensate any organization or individuals for
images and or geometry that are sent.

<p>
p.s.s. Don't send mail asking me about the future conference, since
the only thing we currently know is that it will be sometime in the
spring of 1995.
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.ARL.MIL id aa08338; 14 Mar 94 5:41 EST
Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id aa20418;
          14 Mar 94 5:36 EST
Received: from wharf.brl.mil by WALRUS.ARL.ARMY.MIL id aa20346;
          14 Mar 94 5:25 EST
Received: from godot.lysator.liu.se by WHARF.BRL.MIL id aa29613;
          14 Mar 94 5:06 EST
Received: from maxwell (gorry@maxwell.lysator.liu.se [130.236.254.170]) by godot.lysator.liu.se (8.6.6.Beta2/8.6.6.Beta2) with SMTP id LAA02977 for &lt;cad@brl.mil&gt;; Mon, 14 Mar 1994 11:05:39 +0100
Received: by maxwell
          (4.12/1.34/Lysator-3.1) id AA13778; Mon, 14 Mar 94 11:04:38 -0100
          (unknown)
Date: Mon, 14 Mar 94 11:04:38 -0100
From: G|ran Rydqvist &lt;gorry@lysator.liu.se&gt;
Message-Id: &lt;9403141004.AA13778@maxwell&gt;
To: cad@brl.mil
Subject: Missing makekey on non-US Sun Solaris

<p>

Previously I asked for assistance to unpack the BRL distribution using
Solaris 2.3, as makekey is missing.

I have checked things with Sun Sweden. Makekey is only included in the Solaris
Encryption kit which is not exported from the USA.

I solved the problem as follows:

Insert SunOS 4.1.1 CD
ln -s /cdrom/cdrom0/s0/export/exec/sun4_sunos_4_1_1/usr ~/brl-dir
cd ~/brl-dir
tar xvf usr ./lib/makekey

Further enigma.c need to be modified to use a local makekey by changing one of
the paths to ./makekey.

        if (fork()==0) {
                close(0);
                close(1);
                dup(pf[0]);
                dup(pf[1]);
                execl("./makekey", "-", 0);
                execl("/usr/lib/exec/makekey", "-", 0); /* BSDI */

Thanks for all the help I received.

- Goran Rydqvist
CadCal Design
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.ARL.MIL id aa20570; 5 May 94 12:38 EDT
Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id ab16296;
          5 May 94 11:58 EDT
Received: from wolf.arl.mil by WALRUS.ARL.ARMY.MIL id aa16196;
          5 May 94 11:54 EDT
Date:     Thu, 5 May 94 11:54:22 EDT
From:     "John R. Anderson" &lt;jra@ARL.ARMY.MIL&gt;
To:       Yoav Oreg &lt;phr22yo@phys4.technion.ac.il&gt;
cc:       cad@brl.mil
Subject:  Autocad to BRLCAD Conversion
Message-ID:  &lt;9405051154.aa20174@WOLF.ARL.MIL&gt;

<p>
Yoav Oreg writes:

<p>
&gt; what I tried to do is to build a simple object in auto-cad out of
&gt; primitive solids for instance a box and a cone, translate them to
&gt; IGES format (my autocad supports IGES 4.0) and then by using the
&gt; iges-g module translate the IGES file to brl-cad format.
&gt; everything seemed to be going fine until I applied iges-g.
&gt; The routine started working by counting the number of lines in the
&gt; objects but when it reached the part where it counts the number of
&gt;  solids/regions it counted 0 (zero).

<p>
	While IGES 4.0 supports solid models, what Autocad produced
for you was an IGES "drawing" of the object you built, not a solid
model. The key is that iges-g says it found no solids or regions in
the IGES file. BRLCAD is a solid modeller, so it needs solid objects
to operate on. The iges-g converter distributed with BRLCAD converts
only IGES CSG (Constructive Solid Geometry) objects to BRLCAD format.
Converting a drawing of a solid object (as Autocad provided) to a real
solid model of that object is something people have been dreaming of for
years, but so far it takes human intelligence in the loop.  If Autocad
would support the IGES CSG portion of IGES 4.0, then the conversion
you attempted would work.

<p>
&gt; can someone please give an answer to the problem :what  kind (if
&gt; any) of objects made in autocad can be translated via IGES files to brlcad
&gt;  and  HOW CAN I DO IT?

<p>
	As I mentioned above, if there is a version of Autcad that will
produce IGES 4.0 CSG files, then you can convert them to BRLCAD. One
other possibility is if Autocad can produce IGES 128 entities (NURBS),
the iges-g converter will convert these entities to BRLCAD spline solids
by combining all the 128's in the IGES file into a single spline solid.
Note that this will not work for trimmed NURBS yet.

<p>
	The next release of BRLCAD will include an improved iges-g converter
that will also handle IGES BREP (Boundary Representation) solid models
(restricted to planar-faced objects).  There will also be a "dxf-g" to
convert Autocad's DXF format to BRLCAD, however this will also be limited
to 3D objects (3DFACES and 3DMESH objects) and 2D drawing entities will
be ignored.

<p>

<p>
		Hope this helps,

<p>

<p>
		-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058
<hr>
<hr>
Received: from walrus.brl.mil by WOLF.ARL.MIL id aa21089; 5 May 94 13:42 EDT
Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id aa19332;
          5 May 94 13:39 EDT
Received: from wharf.arl.mil by WALRUS.ARL.ARMY.MIL id aa19206;
          5 May 94 13:32 EDT
Received: from uv2.eglin.af.mil by WHARF.BRL.MIL id aa25905; 5 May 94 13:17 EDT
Date: 5 May 94 12:18:00 CST
From: "Allen R." &lt;REYNOLDS@uv2.eglin.af.mil&gt;
Subject: RE: Modeling Question
To: cad &lt;cad@brl.mil&gt;
Message-ID:  &lt;9405051317.aa25905@WHARF.BRL.MIL&gt;

<p>

<p>
                               E G L I N     A F B

<p>
From:  MILFORD A. REYNOLDS                  Date:     05-May-1994 12:11pm CST
       REYNOLDS                             Tel No:   904 862 4188
Dept:  46TW/EALV*ASI

<p>
TO: (List Suppressed - Enter SH to read list. Use US SWC to remove suppression.)

<p>

<p>
Subject: RE: Modeling Question

<p>
Glenn,
	The only time we've had to deal with pointy-headed ogives we made
do with an RCC at the end with a near-zero radius. In fact, a series of
RCC's with appropriately decreasing radii might make a better approximation
than an ellipsoid.
							Allen Reynolds
							ASI Sys Intn'l

<p>

<p>
<hr>
<hr>
Date:     Sat, 14 May 94 22:08:52 EDT
From:     	 Mike Muuss &lt;mike@arl&gt;
Subject:  new command line parser
To:       mike
Message-ID:  &lt;9405142208.aa27571@WOLF.ARL.MIL&gt;

<p>
		A New Command-Line Option Parser for BRL-CAD

<p>
				ACST Team Meeting
				   18-Feb-1994

<p>

<p>
	--- GOALS ---

<p>
*)  Backwards compatability with current getopt() style command usage,
so that e.g. "pix-fb -hizs32" is understood as a series of 1-char options.

<p>
*)  Opportunity for more options than with present getopt(), e.g. long
option names a.la. X-windows (including abbreviated forms), while also
retaining 1-char options.

<p>
*)  Each 1-char option should have the opportunity for a long option
that does exactly the same thing.

<p>
*)  Eliminate redundancy.  One table should suffice for usage message,
arg/no-arg flagging ("g:"), verbose help message.  It would be nice
to also eliminate the getopt() style switch() statement, perhaps by
including pointers to the variable to be set and/or by having a hooked
function pointer in the table.

<p>
*)  It would be nice to (a) check for proper number of positional
arguments, and (b) perhaps parse them into variables as well.

<p>
*)  It would be nice to have "supplemental text" to supplement the
usage message with, tucked into the same table.  (Perhaps as part of
the NULL entry at the end?)

<p>
*)  It would be nice to have a routine that could print out (or perhaps
return a string with) a command-line which completely represented the
state of the program's options, including showing the values for all
options that were defaulted.

<p>
	--- ISSUES ---

<p>
*)  How to mix long and short forms?  One proposal is to have all
long forms start with a double-minus, e.g.:

<p>
	pix-fb --width 32 -s128 --inverse foo.pix

<p>
This is not incompatible with the getopt() usage of "--" to mark end of
option list, but it is a nuisance to type two minus signs.

<p>
*)  How to determine the minimum acceptable abbreviation for long option
names.  The X strategy of taking the shortest unique substring is
convenient for the programmer, but means that adding new options may
break old shell scripts, e.g. -geometry abbreviated as -geo in a script
would no longer work when a -geodesic flag was added.  The VMS style
alternative would require the programmer to designate the minimum
acceptable substring, which seems preferable.  For example, either
"-geom*etry", or "-GEOMetry" could both be used.

<p>
*)  Long argument names should be case insensitive.  Shouldn't they?
<hr>
<hr>
Received: from walrus.brl.mil by wolf.arl.mil id aa06864; 31 May 94 15:14 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19580; 31 May 94 14:16 EDT
Date:     Tue, 31 May 94 13:54:39 EDT
From:     Bob Strausser (SURVICE ENG. | Jill ) &lt;strssr@ARL.MIL&gt;
To:       merlin &lt;merlin@neuro.usc.edu&gt;
cc:       cad@ARL.MIL
Subject:  iges-g malloc error
Message-ID:  &lt;9405311354.aa18963@WALRUS.ARL.MIL&gt;

<p>
AJ,

<p>
The following message should allow you to fix the malloc error in the iges-g
converter.  You still need "valid" geometry formats (IGES type 128, I think)
for a valid imported spline.

<p>
Bob Strausser
SURVIAC ASO

<p>
forwarded message:
-----------------

<p>
Date:     Mon, 7 Jun 93 13:39:21 EDT
From:     "John R. Anderson" &lt;jra@brl&gt;
To:       Shung-Wu Lee &lt;u10480@u2.ncsa.uiuc.edu&gt;
cc:       cad@BRL
Subject:  [John R. Anderson:  BUG in iges-g]

<p>
There is a small bug is the "iges-g" code that causes it to die on an
rt_malloc error in "rt_nurb_new_snurb".Here is a context diff for the fix:

<p>
*** spline.c.old        Mon Dec 21 15:46:51 1992
--- spline.c    Mon Dec 21 15:50:07 1992
***************
*** 89,95 ****
        b_patch = rt_nurb_new_snurb(
                m1+1, m2+1,
                n1+2*m1+1, n2+2*m2+1,
!               k2+1, k1+1, 4);

        /* U knot vector */
        for (i = 0; i &lt;= n1+2*m1; i++) {
--- 89,95 ----
        b_patch = rt_nurb_new_snurb(
                m1+1, m2+1,
                n1+2*m1+1, n2+2*m2+1,
!               k2+1, k1+1, MAKE_PT_TYPE( 4 , 2 , 0 ) );

        /* U knot vector */
        for (i = 0; i &lt;= n1+2*m1; i++) {

<p>
************************************
John R. Anderson
Attn: AMSRL-SL-BV
U.S. Army Research Laboratory                   Internet: jra@brl.mil
Aberdeen Proving Ground, MD  21005-5068         Phone: (410) 278-6674

<p>
---------------------
end forwarded message

<p>

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa16836; 20 Jun 94 14:59 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13701; 20 Jun 94 13:34 EDT
Received: from worm.arl.mil by WALRUS.ARL.MIL id aa13471; 20 Jun 94 13:26 EDT
Date:     Mon, 20 Jun 94 13:24:39 EDT
From:     "Gary S. Moss" (BVLD/VMB) &lt;moss@ARL.MIL&gt;
To:       browder jr &lt;browder@use1.eglin.af.mil&gt;
cc:       cad@ARL.MIL
Subject:  Re: BRL-CAD and IRIX 5.2
Message-ID:  &lt;9406201324.aa27660@worm.arl.mil&gt;

<p>

<p>
&gt; My problem now is: What and or where are &lt;bsd/sys/types.h&gt; and
&gt; &lt;bsd/sys/time.h&gt;? (Required in fbed/empty.c)

<p>
The use of &lt;bsd/sys/whatever&gt; in fbed/empty.c was to get to the BSD-
flavored stuff under older IRIX releases (probably IRIX 3.x).  Under
IRIX 4.x the BSD stuff was apparently integrated into /usr/include,
so you just want to use &lt;sys/types.h&gt; and &lt;sys/time.h&gt;, but the
/usr/include/bsd directory was still there for backward compatibility.
This compatibility was apparently removed in IRIX 5, so no /usr/
include/bsd anymore.

<p>
In your case, I would just change the CPP directives at the top of
empty.c to always include &lt;sys/types.h&gt; and &lt;sys/time.h&gt;.  I'm not
sure what the politically-correct solution is for the official
BRL-CAD copy.  For instance, making rash statements like, if someone
is still running IRIX 3 or earlier, they probably [...various things
could go in here...], may not be acceptible policy. ;^)

<p>
-Gary

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa16857; 20 Jun 94 14:59 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa14923; 20 Jun 94 14:05 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa14841; 20 Jun 94 14:02 EDT
Date:     Mon, 20 Jun 94 13:58:16 EDT
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       Yoav Oreg &lt;phr22yo@phys4.technion.ac.il&gt;
cc:       cad@ARL.MIL
Subject:  Re:  conversion to BRL-CAD
Message-ID:  &lt;9406201358.aa15527@wolf.arl.mil&gt;

<p>
Yoav Oreg &lt;phr22yo@phys4&gt; writes:

<p>
&gt; This is a follow up question to my last letter concerning conversion from
&gt; AUTOCAD to BRLCAD. I have been talking to some CAD people and for
&gt; some reason they keep on telling me that even if you have a CAD package
&gt; that works with solids, when you convert a solid to IGES format, the solid
&gt; is broken into wire frame which doesn't keep the solid properties. I am quite
&gt; confused now, since I was told last time that IGES does support solid entities?
&gt; could someone enlighten me?

<p>
	The IGES specification includes support for both CSG and BREP
solid models.  It is up to the CAD vendor to decide how much of the IGES
spec they are willing to support.  Users of solid modelling CAD systems should
let their vendors know that they expect to be able to exchange solid models
via IGES without rebuilding the model from wireframe or just a collection
of surfaces in space.

<p>
&gt; also if ,as I understand importation of solids via IGES is possible,does
&gt; any one Know if it is possible to do it from UCLID,UNIGRAPHICS or CATIA?
&gt; and if it's possible than how?

<p>
	The current BRL-CAD distribution include an "iges-g" that will import
IGES CSG solids into the BRL-CAD format.  This means IGES files that contain
entities such as cones, cylinders, blocks, wedges, etc, along with the CSG
specific entities such as Boolean trees, solid assemblies, and solid instances.

<p>
	The next release of BRL-CAD will include an improved "iges-g" that will
also handle IGES BREP files of a limited variety. These files must contain IGES
FACE, EDGE, LOOP, and VERTEX entities (the first release of this converter
will be limited to planar faces).

<p>
&gt; Iam asking this in order to save me a few months work of rebuilding a vehicle
&gt; built in UCLID.

<p>

<p>
	The next release of BRL-CAD will also include a EUCLID-G converter that
converts what EUCLID calls a "decoded" file into the BRL-CAD format. This decoded file
contains an ASCII representation of a facetted approximation of the solid model.

<p>
	Neither of these converters are available until the next release. Both will
be producing a variety of NMG objects that are not supported in the current release.

<p>

<p>
			Hope this helps,
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa19158; 20 Jun 94 17:39 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa20328; 20 Jun 94 16:28 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa20177; 20 Jun 94 16:21 EDT
Date:     Mon, 20 Jun 94 16:17:36 EDT
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       "John C. Stauffer" &lt;13746sta@kcu303.bv.com&gt;
cc:       cad@ARL.MIL
Subject:  Re:  B-Rep's from BRL-CAD
Message-ID:  &lt;9406201617.aa18195@wolf.arl.mil&gt;

<p>
John C. Stauffer &lt;13746sta@kcu303.bv.com&gt; writes:

<p>
&gt; Have there been any proposals to allow for the creation of BRL-CAD model BReps?
&gt;  I realize that there would probably be a lot of work involved (and I'm
&gt; expecting a negative reply), but I was curious if any thought had been given to
&gt; B-Reps at all.  Is there anyone else out there that would like to see this?

<p>

<p>
	As Gomer would say "Surprise, Surprise, Surprise!!!". The BRL-CAD
development team is hard at work on NMG's. This new type of BRL-CAD solid
will allow BRL-CAD users to create BREP objects. Initially, we will be limited
to planar-face objects, but plans are already being made for extending that to
Trimmed-NURB faces.  The next release is expected to include planar-face NMG's.

<p>

<p>
			-John

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa13886; 21 Jul 94 17:32 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24899; 21 Jul 94 16:36 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24733; 21 Jul 94 16:25 EDT
Date:     Thu, 21 Jul 94 20:21:25 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       Mary Foster &lt;foster@gdls.com&gt;
cc:       cad@ARL.MIL
Subject:  Re: Changing color of MGED display window on SGI
Message-ID:  &lt;9407211621.aa08722@wolf.arl.mil&gt;

<p>

<p>
&gt; When we go into the MGED editor, our default window display is black.
&gt; This makes it difficult to see our menu bar and the model in our display
&gt; window.  Is there a way to change the color of the display window ?

<p>
There is currently no way to change the background in MGED to anything
other than black.  However, it should be easy to see the border of the
window and MGED menus, which are drawn in yellow.  The default drawing
color for an object is full-brightness red, which should be easy to see.

<p>
Something else may be going wrong.

<p>
&gt; BRLCAD is installed on our Silicon Graphics workstation.

<p>
What kind of SGI, running what version of the operating system?
What release of BRL-CAD are you running?  4.2?  (MGED prints this
as it's first message).

<p>
If problems persist, please include the output of the SGI 'hinv'
command, so that we can see what kind of CPU and graphics hardware you
have.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa18765; 21 Jul 94 22:54 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa27276; 21 Jul 94 22:00 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa27270; 21 Jul 94 21:52 EDT
Date:     Fri, 22 Jul 94 1:50:47 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       Joel Lazewatsky &lt;lazewajl@lldmpc.dnet.dupont.com&gt;
cc:       cad@ARL.MIL
Subject:  Re: Ray-trace intensity
Message-ID:  &lt;9407212150.aa18012@wolf.arl.mil&gt;

<p>

<p>
&gt; We are creating models of gamma camera collimators in MGED:

<p>
Sounds pretty cool!

<p>
&gt; This seems to work well for point sources, but when we tried to go to
&gt; more complicated light sources, we discovered that the intensity of the
&gt; shadow cast by the collimator dropped dramatically as the source size
&gt; increased.

<p>
This is a general problem with modeling area light sources when
ray-tracing. The general strategy that I implemented in RT is to
represent the light region as a cube (described simply by the radius of
the inscribed sphere).  When firing light visibility rays, the aim
point is perturbed off the centroid of the light region by drawing
three random numbers and perturbing the X Y and Z components of the
aim point separately.  This is sometimes called "dithering the light
visibility ray aim points".

<p>
Sampling area lights with only one ray per pixel tends to produce very
poor (noisy) results in the penumbra areas.  And, you guessed it....

<p>
&gt; Is there a way to increase the number of rays used by rt?

<p>
Yes.  Use the -H# command line option, to "hypersample".  The positive
integer argument ("#") indicates how many _additional_ rays to fire
for each pixel.  Note that this automaticly causes "-J1" to be set,
to cause the start point of the rays to be dithered (which is an
entirely different matter from dithering the light aim points).

<p>
-H causes a simple average of the collected samples to be stored for
each pixel.  This is not the best strategy, but is useful when output
file size is an issue.  (More below).

<p>
How many extra rays will be needed depends on how much noise you are
willing to tolerate, and how large your light source is.  The larger
the light source, the more rays you will probably need to get a "good"
penumbra.

<p>
Typical values for -H range from -H3 to -H15.  Note that this also
results in a linear increase in runtime.  If the runtime for -H0 is X,
then the runtime for -Hnnn is (nnn+1)*X.

<p>
A more satisfying solution is to increase the resolution of the pixel
grid appropriately, and then set -H0 and -J1.  This stores one ray per
pixel, but with full dithering enabled.  After the image has been
written, low pass filter the result and decimate.  One cheap, dirty,
and fast program for doing this is PIXHALVE, which uses a simple 5x5
filter pyramid, and reduces image size by half in both dimensions.

<p>
More sophisticated filter techniques can also be implemented.

<p>
If disk space for the (perhaps 4x or 16x larger) initial .pix file is
not a problem, this strategy gives much better results than the
comparable -H3 or -H15 approach, at identical runtime.  (Not counting
the one or two passes of PIXHALVE, which doesn't add much).

<p>
Why not experiment with -H and/or the filter & decimate strategies,
and see if that meets your needs.

<p>
I'd love to see an image of one of your collimators sometime.  Sounds
like a fascinating application!

<p>
	Best,
	 -Mike

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa07893; 26 Jul 94 11:22 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa00155; 26 Jul 94 9:49 EDT
Received: from smokey.arl.mil by WALRUS.ARL.MIL id aa00047; 26 Jul 94 9:40 EDT
Date:     Tue, 26 Jul 94 9:33:25 EDT
From:     Bob Parker &lt;bparker@ARL.MIL&gt;
To:       gda@msic.dia.mil
cc:       cad@ARL.MIL
Subject:  Re: coordinate information in xmged
Message-ID:  &lt;9407260933.aa10388@SMOKEY.ARL.MIL&gt;

<p>
Glenn,

<p>
Located in the menu bar is the FILE menu which contains an item
called "Show Info". Selecting this will bring up an information
window that will display everything about the current solid/object.

<p>
I hope this helps.

<p>
-Bob
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa09963; 2 Aug 94 17:50 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa08939; 2 Aug 94 16:46 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa08899; 2 Aug 94 16:41 EDT
Date:     Tue, 2 Aug 94 16:34:32 EDT
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       Harry Campbell &lt;harry@delphi.dseg.ti.com&gt;
cc:       jra@ARL.MIL, cad@ARL.MIL
Subject:  Re:  Pro/Engineer Conversion
Message-ID:  &lt;9408021634.aa08293@wolf.arl.mil&gt;

<p>
Harry Campell writes:
&gt; Here at TI we do a lot of modelling with Pro/Engineer.  I would be very
&gt; interested in hearing how you convert those models into BRL-CAD, and the
&gt; code that allows you to do that.
&gt;
&gt; Thanks.

<p>

<p>
	There are actually two codes invloved in conversion from Pro/Engineer
to BRL-CAD.  The first is a Pro/Develop code.  This code uses the Pro/Develop
library that you only get with the Pro/Develop option of Pro/E.  The
resulting executable, however, may be used by other Pro/E sites without
a Pro/Develop license. This code installs an additional menu item (labelled
"BRL-CAD") under Pro/E's "export" menu. Selecting this menu option activates
the code. It then traverses the current object in the Pro/E session and
writes assembly information (member names and transformation matrices) to
an ascii file. Assemblies and sub-assemblies are handled this way. Parts
(the actual solids in a Pro/E model) are output to the same ascii file in
render format using the same routine that Pro/E uses to output objects
in render format (render format is a variety of triangulated facets). One
might ask, "Why not just use Pro/E's render export option?". This was my
first idea also, but as it is implimented in Pro/E, the entire model is
exported as a single solid made up of lots of triangular facets. I wanted
to get the individual parts as seperate objects and the assemblies as
groupings of these objects.

<p>
	The second code converts this ascii file to the BRL-CAD format.
It reads the assembly information and creates BRL-CAD groups. The parts
(solids) are converted to BRL-CAD NMG or polysolid objects according to
a command line option.  A region is constructed for each part and any
color assigned to the part in Pro/E is assigned to the region.

<p>
	Note that the resulting BRL-CAD objects are facetted approximations
of the actual Pro/E model. The quality of the approximation can be controlled
on a scale from 1 to 10, where a quality of 1 may approximate a cylinder as
a rectangular parallelepiped and a quality of 10 might break the cylinder
surface into 20 rectangular facets. It's not that simple as the Pro/E
routine actually uses a combination of chord height (distance from actual
surface to facet approximation) and an angle control that provides additional
improvement along curves with small radii.

<p>
	 Other properties that are used in a BRL-CAD region or group (such
as ident number, los, material code, etc) could be set as user parameters
in Pro/E and detected and assigned to the BRL-CAD group or region. This
has not yet been implimented, and would require a list of user parameter
names to be agreed upon.

<p>
	Hope this answers your question.

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa16351; 4 Aug 94 13:19 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa01153; 4 Aug 94 12:13 EDT
Received: from vgr.arl.mil by WALRUS.ARL.MIL id aa01032; 4 Aug 94 12:02 EDT
Received: from odo.amherst.com by VGR.ARL.MIL id aa06533; 4 Aug 94 15:56 GMT
Received: by amherst.com (5.0/SMI-SVR4)
	id AA24910; Thu, 4 Aug 94 11:54:12 EDT
Date: Thu, 4 Aug 1994 11:51:25 -0400 (EDT)
From: John P Doughtie &lt;jpd@amherst.com&gt;
Subject: Re: Problem with BRL-CAD 4.2 Install
To: cad@ARL.MIL, john dome &lt;batman@nvl.army.mil&gt;
Cc: John P Doughtie &lt;jpd@amherst.com&gt;
In-Reply-To: &lt;m0qW4Wg-0004vtC@nvl.client&gt;
Message-Id: &lt;Pine.3.07.9408041123.H24236-8100000@odo&gt;
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 246

<p>

<p>
On Thu, 4 Aug 1994, john dome wrote:

<p>
&gt; try setting your MANDIR to /xxx/brlcad/man/man and give it a go!
&gt; works for us. hope you find the package useful.

<p>
Thanks.  That worked just fine.  Sorry about the duplicate post on this
subject.

<p>
John

<p>

<p>
<hr>
<hr>
Date:     Tue, 9 Aug 94 15:58:34 GMT
From:     Paul Tanenbaum  &lt;pjt@arl.mil&gt;
To:       mike@arl.mil, butler@arl.mil, jra@arl.mil, stay@arl.mil, gdurf@arl.mil
cc:       pjt@arl.mil
Subject:  MGED(1) source command
Message-ID:  &lt;9408091158.aa27624@wolf.arl.mil&gt;

<p>

<p>
I just implemented one using mged_source_file().

<p>
    Usage: source file/pipe
	    (read and process file/pipe of commands)

<p>
Like MSG(1), it decides whether to use POPEN(2) or FOPEN(2) by checking
whether arg[1][0] is '|'.  Is there anybody else I should inform about it?

<p>
     Paul

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa24426; 7 Aug 94 17:08 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa05497; 7 Aug 94 15:51 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa05484; 7 Aug 94 15:44 EDT
Date:     Sun, 7 Aug 94 15:36:35 EDT
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       Harry Campbell &lt;harry@delphi.dseg.ti.com&gt;
cc:        cad@ARL.MIL
Subject:  Re:  Pro/Engineer Conversion
Message-ID:  &lt;9408071536.aa24062@wolf.arl.mil&gt;

<p>
Harry Campbell writes:

<p>
&gt; You sent me some information about software that will convert
&gt; Pro/Engineer databases into BRLCAD databases.  Let me make sure that I
&gt; understood you correctly.
&gt;
&gt; I need to have the Pro/Develop library.  This I assume is a purchased
&gt; add-on to the Pro/Engineer package.

<p>
	No, You do not need any additional Pro/Engineer modules.  You will
obtain the executable from us (ARL), and you will create a small ascii file
called "prodev.dat" that informs Pro/Engineer about the BRL-CAD Application.
The Pro/Develop library is only required if you are going to write your own
Pro/Develop applications.

<p>
&gt;                                      I need to have this second piece of
&gt; software that converts the ascii output from Pro/Engineer into a BRLCAD
&gt; database.  I will guess that this second file is going to be freely
&gt; available with the BRLCAD software distribution?

<p>
	Yes, that is correct.

<p>

<p>
			Hope this clears things up!
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa28962; 21 Aug 94 21:09 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa09517; 21 Aug 94 20:25 EDT
Received: from vgr.arl.mil by WALRUS.ARL.MIL id aa09515; 21 Aug 94 20:21 EDT
Received: from rumors.delta.edu by VGR.ARL.MIL id aa00369; 22 Aug 94 0:06 GMT
Received: by rumors.delta.edu (AIX 3.2/UCB 5.64/4.03)
          id AA07738; Sun, 21 Aug 1994 19:58:03 -0400
Date: Sun, 21 Aug 1994 19:58:03 -0400
From: laut@rumors.delta.edu
Message-Id: &lt;9408212358.AA07738@rumors.delta.edu&gt;
To: cad@brl.mil
Subject: Re:Suggestion for LIBRT

<p>

<p>

<p>
&gt;&gt; The thing which inspired this:  I was playing around today with sh_marble.c,
&gt;&gt; trying to create a link in a chain out of a couple of tori and cylinders,
&gt;&gt; and noticed that a change in region caused the turbulence to change.
&gt;
&gt;As an alternative, perhaps the origin of the texture could optionally be
&gt;anchored to a point in space.  Either specified numerically, or
&gt;symbolically, something like a/b/crod.r/foo.cyl[TIP].
&gt;
&gt;That would seem like a more direct method of achieving the control sought.
&gt;
&gt;&gt; My proposed suggestion:  For the next release of BRL-CAD, could you please
&gt;&gt; add a field to "struct region" in raytrace.h which points to the directory
&gt;&gt; entry from which the region was created, [...]
&gt;
&gt;It's encoded in the reg_name, in an inconvient format. Perhaps instead
&gt;of storing the name, the db_full_path info should be kept instead.  Takes
&gt;about the same amount of space either way.  An rt_vls_??? routine to
&gt;format the db_full_path info into a VLS string would be the only thing
&gt;needed to make the interface clean.
&gt;
&gt;	Thoughts?
&gt;

<p>
After posting my suggestion, I developed a workaround that basically
does the same thing.  In the case of sh_marble, it involves adding an
"identification" integer to marble_specific, in order to group marble
regions by some arbitrary, MATPARM-specified value.  IE,

<p>
	struct marble_specific {
		struct marble_specific  *forw;
		int                     ident;
		...
	};

<p>
	static struct marble_specific *Marble_Chain;

<p>
and

<p>
	struct structparse marble_parse[] ={
		{"%d",  1, "id", MARB_O(ident), BU_STRUCTPARSE_FUNC_NULL },
		...
	};

<p>
When the regions are being set up, the Ident field is inspected to see
if a non-zero value was returned by rt_structparse().  If so, it is
added to a singly-linked list headed by "Marble_Chain".  The list is
then scanned to find all regions which match the Ident, and VMIN/VMAX is
called against all of them to find a bounding RPP which encloses all
regions of note.  Once the scan is completed, the results of VMIN/VMAX
are then propogated to all matching regions.  This can obviously be
improved, but it presently gets the job done.

<p>
An example of this has been uploaded to wolf:/incoming/link.pix.Z.  "Link"
is a 512x512 raytraced image of a link out of a chain, using the modified
marble shader to produce the body color and an experimental dielectric
shader to do shadowing (although the specular reflection did get overexposed
in order to better contrast the turbulence).  With the exception of the
upper right joint, the results are nice and smooth.

<p>
From a modelling perspective, this approach wins hands down over changing
LIBRT, because it allows the modeller to explicitly tell the shader which
*combinations*, taken together, are "cut from the same stone."

<p>
Finally, I can see where this approach would be useful in rendering
sculpted CSG glass by allowing you to explicitly declare which regions are
of the same composite material, so that refract.c doesn't have to guess
which regions are continuations of one another.  An example of what I
am referring to are the "Hurricane Lamps" on page 24 of the April 1994
issue of Computer Graphics World, and the seams which show up at the top
of the lamps where the tori joins the body but not elsewhere.

<p>
-Bill

<p>

<p>

<p>

<p>
<hr>
<hr>
Date:     Mon, 22 Aug 94 20:26:31 GMT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       acst@arl.mil, AYoung@arl.mil, Jill@arl.mil, PHD@arl.mil, PJT@arl.mil,
           Davisson@arl.mil, WM@arl.mil, GDurf@arl.mil, Moss@arl.mil
cc:       wbowman@arl.mil, gillis@arl.mil, reed@arl.mil, CJohnson@camelot.com
Subject:  RT timing on IRIX 5
Message-ID:  &lt;9408221626.aa21854@wolf.arl.mil&gt;

<p>

<p>
I fixed a bug in rt_get_timer()/rt_read_timer() that was resulting in
improper performance measurements of runtime on SGI systems.

<p>
I upgraded rt/do.c to use rt_get_timer() in place of rt_read_timer()
so that I could get wallclock as well as CPU time.  And then upgraded
the RT statistics output to display the statistics in *all* the
different ways that are commonly interesting:

<p>
Frame     0:    65536 pixels in       3.04 sec =   21551.98 pixels/sec
Frame     0:    76479 rays   in       3.04 sec =   25150.67 rays/sec (RTFM)
Frame     0:    76479 rays   in      12.16 sec =    6287.67 rays/CPU_sec
Frame     0:    76479 rays   in       3.17 sec =   24157.05 rays/sec (wallclock)

<p>
The first two are conventional (and now are correct!), while the second
two are new.

<p>
The "rays/sec" figure is a measure of the performance of the SYSTEM
(presumably "all" CPUs running), while the "rays/CPU_sec" figure is a
measure of the efficiency of the system.  "rays/sec (wallclock)", on an
unloaded system, is an indicator of actual results, and takes into
account I/O speeds, paging, OS overhead, etc.

<p>
One of the most important bugs pending for this release has now been
fixed! Onward to the rest of them.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa16088; 16 Aug 94 14:51 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa29107; 16 Aug 94 13:48 EDT
Date:     Tue, 16 Aug 94 13:42:02 EDT
From:     Bob Strausser (SURVICE ENG. | Jill ) &lt;strssr@ARL.MIL&gt;
To:       Robert Coderre &lt;rcoderre@cals1.belvoir.army.mil&gt;
cc:       cad@ARL.MIL
Subject:  BRL-CAD on IRIX 5.2
Message-ID:  &lt;9408161342.aa28929@WALRUS.ARL.MIL&gt;

<p>
Robert,

<p>
You are running into problems with changes in the IRIX operating system.  The
errata are for the IRIX 4.0.5 operating system but you are using IRIX 5.2.

<p>
The Cakefile.defs need to be edited for the current BRL-CAD release to
compile on IRIX 5.2.  The following comments were extracted / edited from
email traffic concerning the install:

<p>
If you set the SGI_CC environment to -cckr This should fix your problems.

<p>
setenv SGI_CC -cckr

<p>
Also take a look at the Cakefile.defs and see the new CFLAGS definitions
(Irix 5.2 uses the R4000; in the Cakefile.defs the following under
machinetype 5d is found)

<p>
/*      For R4000 machines you might want to include -KPIC -kpicopt -mips2 on the next line */
/*      instead of -G 15 */
#       define  GFLAG           -KPIC -kpicot -mips2
/*#     define  GFLAG           -G 15  */
/*      ANSI+POSIX mode is used over ANSI, to get fdopen(), etc, defined. */
/*#     define  CC_OPTS         GFLAG -ansiposix -DXLIB_ILLEGAL_ACCESS=1 */
#       define  CC_OPTS -cckr   GFLAG -DXLIB_ILLEGAL_ACCESS=1

<p>

<p>
Bob Strausser
SURVIAC ASO

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa25349; 8 Sep 94 9:40 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa06998; 8 Sep 94 9:39 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa06814; 8 Sep 94 9:28 EDT
Date:     Thu, 8 Sep 94 9:26:21 EDT
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       laut@rumors.delta.edu
cc:       cad@brl.mil
Subject:  Re:  CATIA translator
Message-ID:  &lt;9409080926.aa25172@wolf.arl.mil&gt;

<p>
B. Laut asks:

<p>
&gt; Is there a translator for converting CATIA to BRL-CAD and/or vice-versa?

<p>

<p>
	Not directly, but the next release of BRL-CAD will include a
Pro/Engineer to BRL-CAD converter, and Pro/Engineer can eat CATIA models.

<p>

<p>

<p>
			-John

<p>
<hr>
<hr>
Date:     Sat, 10 Sep 94 9:02:13 GMT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       acst@arl.mil, AYoung@arl.mil, Jill@arl.mil, PHD@arl.mil, PJT@arl.mil,
           Davisson@arl.mil, WM@arl.mil, GDurf@arl.mil, Moss@arl.mil,
           BParker@arl.mil
Subject:  vertexuse attribute normals
Message-ID:  &lt;9409100502.aa16715@wolf.arl.mil&gt;

<p>

<p>
If there are vertexuse attribute normal vectors in an NMG, "ev -w -n"
will now draw them as little hairs, just like the face normal vectors.

<p>
John's additions to the sphere tessellator to *calculate* the vertexuse
attribute normals works very nicely, for the one case I tried.  Good
show, John!

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from wumpus.arl.mil by wolf.arl.mil id aa00442; 14 Sep 94 10:20 EDT
Date:     Wed, 14 Sep 94 10:15:05 EDT
From:     Carl Moore &lt;cmoore@ARL.MIL&gt;
To:       acst@ARL.MIL
cc:       cad@ARL.MIL
Subject:  mged -- long-name failure for idents command
Message-ID:  &lt;9409141015.aa23148@WUMPUS.ARL.MIL&gt;

<p>
It has come to my attention THROUGH A COLLEAGUE'S PROBLEM that using a
long file name in mged's "idents" command is causing a strange failure
(unexplained "sh" message and the idents file getting only the first
half of its normal output).  So I got a test case which I am including
twice in this message (for the sake of readability, the second one has
capital letter X replacing the word "supercalifragilisticexpialidocioius").
The colleague got the problem when he used a full directory path in the
filename argument.

<p>
Here is the original display of my test case:

<p>
mged&gt; idents supercalifragilisticexpialidocioussupercalifragilisticexpialidocious compartment
Summary written in: supercalifragilisticexpialidocioussupercalifragilisticexpialidocious
Processed 1614 Regions
sh: isticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocious: not found
mged&gt;

<p>
Here is the display with X edited in place of the long word:

<p>
mged&gt; idents XX compartment
Summary written in: XX
Processed 1614 Regions
sh: isticexpialidociousXX: not found
mged&gt;

<p>
If the command is going to fail because of a long file name, please make
sure it fails in a sensible way.  Thanks.
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa08148; 14 Sep 94 14:42 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa12893; 14 Sep 94 13:18 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id ab12605; 14 Sep 94 13:08 EDT
Date:     Wed, 14 Sep 94 17:07:53 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       Carl Moore &lt;cmoore@ARL.MIL&gt;
cc:       cad@ARL.MIL
Subject:  Re: mged -- long-name failure for idents command
Message-ID:  &lt;9409141307.aa05710@wolf.arl.mil&gt;

<p>

<p>
Carl Moore wrote about -

<p>
&gt; long file name in mged's "idents" command is causing a strange failure

<p>
I have tracked this down to some ancient string handling code in
mged/utility1.c which was using small pre-allocated arrays to hold the
file name.  (Does the number 80 characters ring any bells for people?)

<p>
I replaced the code with new code using rt_vls (variable length string)
calls, and it works fine now.  I also had mged print out the Shell
commands it was running, so you could see what it was up to.

<p>
The fix will be available in the Alpha release, Real Soon Now.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa23518; 20 Sep 94 3:04 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa25556; 20 Sep 94 2:18 EDT
Received: from admii.arl.mil by WALRUS.ARL.MIL id aa25504; 20 Sep 94 2:14 EDT
Date:     Tue, 20 Sep 94 2:04:57 EDT
From:     Phil Dykstra &lt;phil@ARL.MIL&gt;
To:       Timothy G Smith - Special Projects &lt;tgsmith@sun.com&gt;
cc:       cad@ARL.MIL
Subject:  Re:  if_X.c
Message-ID:  &lt;9409200204.aa00484@ADMII.ARL.MIL&gt;

<p>
| Are there any plans to fix/replace/significantly change libfb or
| if_X.c in TNR?

<p>
Libfb and if_X.c have changed very little since the last release.

<p>
| I am halfway through implementing 24 bit support and would rather not
| put much more effort into this if I am only going to have to redo
| things for TNR.

<p>
We would be happy to get your code.  It shouldn't be very hard to
merge with our version.

<p>
| I only have True Color 24 bits framebuffers so I don't have to worry
| about 24 bit color maps.  How common are Direct Color framebuffers?

<p>
Libfb implements a Direct Color model (since back when real frame buffers
were all 24-bit + colormaps and X didn't exist yet).  So to do full
libfb semantics on a True Color display you need to do software color
mapping.  The SGI X servers provide both True Color and Direct Color
(though we don't use X for 24-bit color on the SGI's).  I don't know
how many other servers provide Direct Color.

<p>
- Phil
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa20900; 19 Sep 94 20:32 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa23722; 19 Sep 94 19:46 EDT
Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa23664; 19 Sep 94 19:36 EDT
Received: from Sun.COM by wharf.arl.mil id aa23673; 19 Sep 94 19:05 EDT
Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
	id AA19401; Mon, 19 Sep 94 16:09:17 PDT
Received: from spdev.East.Sun.COM (spdev-gw.East.Sun.COM) by East.Sun.COM (4.1/SMI-4.1)
	id AA06777; Mon, 19 Sep 94 19:08:47 EDT
Received: from spot.East.Sun.COM by spdev.East.Sun.COM (5.0/6.1-spdev1) id AA05570; Mon, 19 Sep 1994 19:07:49 +0500
Received: by spot.East.Sun.COM (5.x/SMI-SVR4)
	id AA02141; Mon, 19 Sep 1994 19:08:44 -0400
From: Timothy G Smith - Special Projects &lt;tgsmith@sun.com&gt;
Message-Id: &lt;9409192308.AA02141@spot.East.Sun.COM&gt;
Subject: if_X.c
To: cad@ARL.MIL
Date: Mon, 19 Sep 1994 19:08:43 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 676

<p>
Are there any plans to fix/replace/significantly change libfb or
if_X.c in TNR?

<p>
I am halfway through implementing 24 bit support and would rather not
put much more effort into this if I am only going to have to redo
things for TNR.  I have things working well enough that I can now
squirt 24 bit pix files to the screen which is all I need to get done
for a demo on Wednesday.

<p>
I am currently going through all of the routines adding a switch to
handle the 24, 8, and 1 bit code paths but don't know if I will finish
it.

<p>
I only have True Color 24 bits framebuffers so I don't have to worry
about 24 bit color maps.  How common are Direct Color framebuffers?

<p>
thanks,
--tim
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa25477; 21 Sep 94 19:35 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa15001; 21 Sep 94 19:34 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa14974; 21 Sep 94 19:29 EDT
Date:     Wed, 21 Sep 94 23:26:59 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       Pierluigi Barabino &lt;scazzola@relay.marconi.it&gt;
cc:       cad@ARL.MIL
Subject:  Re: BRL-CAD on IRIX 5.2
Message-ID:  &lt;9409211926.aa25396@wolf.arl.mil&gt;

<p>

<p>
&gt; I run now in some problems running mged and xmged:
&gt; - mged attached to sgi displays a black window, program output flashes on
&gt;   refresh so I think it could be a color map problem (?)

<p>
Inside cad/mged/dm-4d.c, you might need to add a few more "case"
statements, so that the code looks something like this:

<p>
                case INV_VGX:
                case INV_VGXT:                  /* VGX Turbo and SkyWriter */
                case INV_GMDEV:                 /* GT graphics */
                case INV_CG2:
                        ir_is_gt = 1;
                        ir_has_zbuf = 1;
                        ir_has_rgb = 1;
                        ir_has_doublebuffer = 1;
                        break;

<p>
&gt; - mged attached to X seems to work, on moss.g "ev all.g" works but the command
&gt;   "facetize new.g all.g" causes a segmentation fault.

<p>
This is a known bug.  BRL-CAD Release 4.0 and 4.2 will die like that on
all platforms.

<p>
This is fixed in the development version of the software.  We are in the
final throes of getting the 4.4 Alpha release ready.  4 weeks after Alpha
(internal tests) we will have a Beta release (for interested sites), and
4 weeks after that we will have a formal BRL-CAD 4.4 release.

<p>
&gt; - xmged (on X) on the same command gives the messages:
&gt;   "mged_nmg_doit: bad op 0" (repeated 6 times)
&gt;   "facetize:  no resulting region, aborting"
&gt;   while "ev all.g" gives the same 6 bad op msgs and then core dumps writing
&gt;   "db_free_tree: bad op".
&gt;
&gt; - xmged attached to sgi doesn't show the colormap problem but the NMG related
&gt;   problems remains.

<p>
The fact that XMGED gives different error messages is disturbing.  I
would have expected it to fail in exactly the same way as MGED.  :-)
I'll check into this.

<p>
&gt; BTW what's the difference between the 4.0 and 4.2 releases?

<p>
BRL-CAD 4.2 contains a small handful of patches, to keep up with SGI's
continuously evolving and (only slightly) incompatible versions of IRIX.

<p>
	Best,
	 -Mike Muuss
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa28828; 30 Sep 94 20:14 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa18869; 30 Sep 94 20:12 EDT
Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa18708; 30 Sep 94 20:02 EDT
Received: from ghost.camelot.com by wharf.arl.mil id aa04465;
          30 Sep 94 19:32 EDT
Received: by camelot.com (931110.SGI/-A/UX-AMR-1.0)
	id AA20077; Fri, 30 Sep 94 19:32:18 -0400
From: "Christopher T. Johnson" &lt;cjohnson@camelot.com&gt;
Message-Id: &lt;9409302332.AA20077@camelot.com&gt;
Subject: Re: Closed Bug#75: librt prep of database with &gt; 100,000 solids is very slow (fwd)
To: cad@ARL.MIL
Date: Fri, 30 Sep 1994 19:32:16 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4471

<p>
This was first sent to the bugs list for the alpha test.  I'm forwarding
it to the main list because I'm more than a little impressed with
what Mike has done to improve the speed of processing large models
and also because there might be some people intrested in the discussion
of swapping, paging and large models.
	Chris

<p>
Mike wrote:
&gt; The real problem here is that the subroutine rt_find_identical_solid()
&gt; has an O((nsolid/128)**2) search, in order to check to see if a new
&gt; solid about to be prepped is really an instance of an existing solid at
&gt; the same location and orientation.  The reason for it being (nsolid/128)
&gt; and not (nsolid) is because there are 128 different solid hashes,
&gt; and rti_solidheads[128] heads 128 different linked lists of struct
&gt; soltabs.  This reduces the search time by a constant factor, but does
&gt; not change the basic n**2 order of the search.

<p>
Very good point, I noticed the improvement when this code was installed.
About an 8 or 10 times speed up in this stage of the prep code.  Call it
12+ cpu minutes to 1.25 minutes.  Now to track down the next slow part.

<p>
&gt; This issue had come up once before, in terms of prep time for large
&gt; models.  I had addressed this issue by speeding up the matrix
&gt; comparisons, and by permitting the rt_find_identical_solid() search to
&gt; spread across up to three processors.  That provided perfectly
&gt; acceptable performance for models of O(5000) solids on ARL's multi-CPU
&gt; SGI machines.

<p>
Also, most of Mike's machines have a little more memory than mine.  So
the O(n**2) problem, while being very real, did not show the devistating
VM crawl that shows up on a small memory machine.

<p>
&gt; Chris is running on a single-CPU machine, has O(110,000) solids, and
&gt; lots of instancing, so this issue has returned.  What is called for is a
&gt; less expensive algorithm.  The current code searches the list of already
&gt; prepped solids to find other instances of the current solid.

<p>
As of last night O(500,000) and moving up.  Each tree is O(2000) solids
with out leaves and O(4000) with leaves, each target of interest is
O(8000) solids.  We are moving towards a scene with O(120,000) trees,
O(500) targets of interest, O(10000) detail items (Telephone poles,
roads, fences, dogs, cats, bears, sheds, churches et so forth).

<p>
We hope to be generating this sort of image sometime in the next two
weeks.  Oh yea, this doesn't include the 192 square kilometers of
terrain data.  That is also included.

<p>
Some comments on generating large models:

<p>
The size of our models are fairly large, but generally of O(10000) solids.
It is only when we start combining them in interesting ways that the
total size of the data base become large.

<p>
All of the large scale database generation is driven by control files
describing placement of targets within the environment.  I.e. where
each tree goes, where each target goes, where each detail item goes.

<p>
These control files also describe transformations that help hide the fact
that there are a limited number of types.  For example, we only have
5 types of trees right now, but those trees get twisted, squashed, expanded,
tilted and moved explicitly for each placement.

<p>
Each target can be individuly configured after the fact with anim scripts.

<p>
MEMORY:
Somebody said: Swapping is BAD.  This is not true.  PAGING is bad.

<p>
The time to trace my complex images in a small memory box is not much
different than the time to trace the same images in a large memory
box.  The reason for this is one Mike Muuss.  The actuall raytracing
is very memory coheasive.  There is NO noticable PAGING going on during
the tracing of a 180MB scene (Total size of rt process) in a 64MB
machine.

<p>
The PREP time, on the other hand is very nasty and is memory dependent.
The doubly linked list that Mike just added reduced the paging enormously
while building the tree.  The next step in the process seems to be doing
an O(n^2) process as well, but I have not instrumented the code enough
to be able to determine where this is happening.

<p>
Many thanks and Ataboys to Mike and his team.

<p>
&gt;
&gt; By the way, this work was pretty easy, thanks to the new "multiple
&gt; rt_list per structure" support I added to rtlist.h a few weeks ago.
&gt; Without that support, this new algorithm would have been a pain to
&gt; code.  Power tools!

<p>
Yes, a very nice addition.  Now we can have cross threaded doubly
linked lists to confuse the best of them.  *GRIN*  But this is
a needed addition, thanks again.

<p>
	Chris

<p>

<p>

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa19613; 15 Nov 94 13:07 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa04473; 15 Nov 94 11:58 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa04330; 15 Nov 94 11:49 EST
Date:     Tue, 15 Nov 94 11:45:13 EST
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       joe edward meier &lt;jem@bruker.com&gt;
cc:       BRL-MIL &lt;CAD@brl.mil&gt;
Subject:  Re:  Changing View with adc
Message-ID:  &lt;9411151145.aa18422@wolf.arl.mil&gt;

<p>
From joe edward meier &lt;jem@bruker.com&gt;:

<p>
&gt;   If I am editting a large object/solid and I have the Angle Distance
&gt; Cusor (adc) showing and placed at say one end of the object, how can
&gt; I then change the view so that I see mostly the other end of the object,
&gt; without the adc moving also?  I have not been able to figure out how
&gt; to do that.

<p>
	Not sure exactly what you mean by this, but the ADC will not move
when the view is changed. If you want to keep the ADC over a particular
point in your model, you can use "adc xyz x_coord y_coord z_coord". This
will position the ADC in front of the specified coordinates. You will need
to execute the same command every time the view changes. Do an "adc help"
for more info.

<p>
&gt;   I also was wondering how one does object selection via the keyborad?
&gt; If you have alot of objects displayed, then it can be imbossible to select
&gt; the object you want via the "object illum" command?
&gt;
	"press oill" will put you in object illuminate mode.
	"ill object" will illuminate the specified object and allow you
to select which matrix along the path should be modified. One problem with
this approach is that if the object appears in more than one path, you
will get the message "object multiply referenced" and the "ill" command
will fail. You can use "paths object" to see what paths the object appears in.

<p>

<p>
		Hope this helps,
			-John
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa18861; 15 Nov 94 12:37 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa05275; 15 Nov 94 12:30 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa05126; 15 Nov 94 12:20 EST
Date:     Tue, 15 Nov 94 12:19:07 EST
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       "Bruce C. Patterson" &lt;pattersb@uy1.eglin.af.mil&gt;
cc:       cad@ARL.MIL
Subject:  [Mike Muuss:  Re: [Marlon Harris: ACAD conversion codes]]
Message-ID:  &lt;9411151219.aa18720@wolf.arl.mil&gt;

<p>
from Bruce C. Patterson (pattersb@uy1.eglin.af.mil):

<p>
&gt; The ultimate goal is to use the Irma 3.2 USAF developed software package to
&gt; create images for optical filter construction.  Irma 3.2 currently uses the
&gt; Advanced Computer Aided Design (ACAD) faceted model discription.  Most of the
&gt; target models we require have been designed using BRL-CAD or FASTGEN.  What
&gt; we need is an avenue that allows us to move BRL-CAD and FASTGEN models into
&gt; ACAD for internal component removal and facetization.  What is the simplest
&gt; way to accomplish this?

<p>
        "patch-g" will convert FASTGEN to BRL-CAD, but we don't have any
ACAD converters. See forwarded message below:

<p>

<p>

<p>
				-John

<p>
----- Forwarded message # 1:

<p>
Date:     Wed, 10 Aug 94 23:01:23 GMT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       Marlon Harris &lt;harris@batman.dynetics.com&gt;
cc:       John R. Anderson &lt;jra@arl&gt;
Subject:  Re: [Marlon Harris: ACAD conversion codes]
Message-ID:  &lt;9408102301.aa26227@wolf.arl.mil&gt;

<p>

<p>
&gt; I would also like to find out if anyone has developed a code that can
&gt; convert ACAD models to BRL-CAD component models.  We have used ACAD to
&gt; convert a file to BRL-CAD format, however when it was loaded into
&gt; BRL-CAD it turned out to be one solid object instead of a component
&gt; model.

<p>
Tools to convert between BRL-CAD and ACAD in both directions are
provided by the ACAD group at Lockheed (formerly General Dynamics),
not as part of BRL-CAD.  You should probably address your difficulties
to J.P. Abalane (unsure of spelling) in the ACAD group.  Sorry I can't
provide more information.

<p>
	Best,
	 -Mike Muuss

<p>
	  Leader, Advanced Computer Systems Team
	  Survivability and Lethality Assessment Directorate
	  The US Army Research Laboratory
	  APG, MD  21005-5068  USA

<p>
	  &lt;Mike @ ARL.MIL&gt;

<p>
	  410-278-6678 Voice
	  410-278-5058 FAX

<p>

<p>
----- End of forwarded messages
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa00206; 19 Nov 94 5:47 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24839; 19 Nov 94 5:02 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24816; 19 Nov 94 4:52 EST
Date:     Sat, 19 Nov 94 9:41:03 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
Subject:  No new registration needed for BRL-CAD 4.4
Message-ID:  &lt;9411190441.aa29487@wolf.arl.mil&gt;

<p>

<p>
Several people have recently asked whether they will have to re-register
with us or send in a new copy of the agreement form in order to obtain
a copy of BRL-CAD Release 4.4.

<p>
The answer to this question for FTP ("free") users is ---&gt; NO &lt;---.

<p>
Release 4.4 is a maintenance release, and is covered by your existing
agreement. The files for anonymous FTP will be encrypted using the same
encryption key as Release 4.0 and 4.2 were.

<p>
For folks who purchased the mag-tape version from SURVIAC, I don't know
whether there will be an additional tape-copying fee or not.

<p>
We anticipate undertaking a complete re-registration, with slightly
updated and streamlined agreement forms, for BRL-CAD Release 5.0, which
is scheduled for the end of FY95 (e.g. October 95, if not before).

<p>
	Best,
	 -Mike

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa29997; 19 Nov 94 5:25 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24784; 19 Nov 94 4:50 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24779; 19 Nov 94 4:41 EST
Date:     Sat, 19 Nov 94 9:35:42 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
Subject:  Beta test of BRL-CAD Release 4.4 now available
Message-ID:  &lt;9411190435.aa29446@wolf.arl.mil&gt;

<p>

<p>
I'm pleased to announce that the Beta-test version of BRL-CAD Release
4.4 (numbered 4.3 to distinguish it from the final Release) is now
available.

<p>
All current BRL-CAD users are invited to FTP the Beta test materials
from host FTP.ARL.MIL, directory brl-cad/Rel4.3/src, where you will
find these files:

<p>
-r--r--r--   1 mike     graphics 7228576 Nov 19 04:13 cad4.3.tar-a.Z
-r--r--r--   1 mike     graphics 2136727 Nov 19 04:15 cad4.3.tar-b.Z
-r--r--r--   1 mike     graphics 1696243 Nov 19 04:15 cad4.3.tar-c.Z
-r--r--r--   1 mike     graphics 2134725 Nov 19 04:16 cad4.3.tar-d.Z
-r--r--r--   1 mike     graphics 1063147 Nov 19 04:16 cad4.3.tar-e.Z
-r--r--r--   1 mike     graphics  745347 Nov 19 04:17 cad4.3.tar-f.Z
-r--r--r--   1 mike     graphics 1892694 Nov 19 04:17 cad4.3.tar-g.Z

<p>
The encryption key for these files is the same as was used for Release
4.0 files.

<p>
There is a mailing list which is being used for discussion of bugs
and issues uncovered in the Beta test period.  This list is
&lt;cad-beta@arl.mil&gt;, and you are welcome to subscribe to it even if
you are not planning to Beta-test the software.  Send E-mail to
&lt;cad-beta-request@arl.mil&gt; to join the list.

<p>
The Beta release contains a shell script "cadbug.sh" which all
Beta-testers are encouraged to use to report bugs in Release 4.3 with.

<p>
I apologize for the 3 week delay in getting the Beta release out.
The arrival of our first SGI "TFP" system with R8000 cpus caused far
more work in porting and bug hunting than had been anticipated. During
the Alpha test period more than 175 bug reports were filed.  Of those,
only 21 remain open as we enter the Beta test period.  I'm confident
that this will be a very successful release, even in light of the
substantial amount of new code since Release 4.2 (more than 200,000 lines!)

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa08658; 22 Nov 94 13:39 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa14957; 22 Nov 94 12:22 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa14896; 22 Nov 94 12:17 EST
Date:     Tue, 22 Nov 94 12:10:30 EST
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       cad@ARL.MIL
cc:       muves-tech@ARL.MIL
Subject:  New Sketch Capability in BRL-CAD's MGED
Message-ID:  &lt;9411221210.aa07525@wolf.arl.mil&gt;

<p>
	Using a method suggested by Mike Muuss, I have added a
rudimentary sketch capability to MGED.  This allows a user to
build a sketch (limited to a single loop currently) in MGED, and
then extrude that loop linearly in any direction (except parallel
to the plane of the loop). The sketch is actually an n-Manifold
Geometry (NMG) loop and when extruded, it becomes an NMG solid.

<p>
	The user begins by creating a nearly empty NMG using
the "make" command in MGED. The only geometry in an NMG created this
way is a single "wire" loop, consisting of a single edge that runs
to and from the same vertex.

<p>
	After selecting this new NMG for editing (you may have to
use the "sed" command, since the new NMG is very tiny - one vertex),
the user selects the only edge by using the "pick edge" menu item
and selecting with the mouse anywhere in the MGED window (the only
edge will be selected).

<p>
	Next, the user may select "split edge" and then use the mouse
to indicate where the new vertex should be positioned. The first mouse
selection, splits the selected edge and places the new vertex at the
mouse location creating a loop of two edges (looks like a single line).
The currently selected edge automatically shifts to the new edge,
and the user may select another location. This selection splits the
current edge and moves the new vertex to the selected location, creating
a triangular loop. The user may continue to build the sketch by repeatedly
selecting points with the mouse or using the "p" command.

<p>
	There is also a "delete edge" menu item that will delete the
currently selected edge, and a "move edge" menu item to allow moving
an edge perpendicular to its length.

<p>
	The sketch is mantained always as a loop, and when the user
is satisfied with the sketch, the "extrude loop" menu item may be
selected to produce an extruded solid. This works similar to other
solid editing items as the user may use any number of mouse point
selections or "p" commands to produce different extrusions until
the desired effect is accomplished.  Then the usual "ACCEPT" or
"REJECT" menu item is selected.

<p>
	The "split edge" and "delete edge" menu items are currently
restricted to use on "wire" loops or "wire" edges. They will not work
on solid NMG objects. "Move edge" will work on simple NMG solids as well
as "wire" edges, and the "extrude loop" will only work on NMG's that
contain a single "wire" loop.

<p>
	Most of these capabilities are in the current BETA release,
but the "extrude loop" wasn't completed until last night (Nov 21).
It will appear in any new BETA releases and in the final 4.4 release.

<p>
			-John
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa23161; 23 Nov 94 9:01 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa04134; 23 Nov 94 8:55 EST
Date:     Wed, 23 Nov 94 8:48:15 EST
From:     Bob Strausser (SURVICE ENG. | Jill ) &lt;strssr@ARL.MIL&gt;
To:       cad@ARL.MIL
Subject:  BRL-CAD (4.3 / 4.4) acquisition - SURVIAC users
Message-ID:  &lt;9411230848.aa03981@WALRUS.ARL.MIL&gt;

<p>
SURVIAC full support users have two choices for acquiring the version 4.4
release (beta and final).  Either:

<p>
	1.  Download the source files from the ftp site in the encrypted form
	    and contact the SURVIAC ASO for the decryption key

<p>
		phone: (410) 273-7794
		fax:   (410) 272-6763

<p>
or

<p>
	2.  Forward a 1/4" cartridge tape or a 4mm DAT tape to the SURVIAC
	    ASO to have the files written to the tape and mailed back.  The
	    mailing address is:

<p>
		SURVIAC ASO
		1003 Old Philadelphia Road
		Suite 103
		Aberdeen, Maryland 21001-4026

<p>
Bob Strausser
SURVIAC ASO
<hr>
<hr>
Received: from wolf.arl.mil by wolf.arl.mil id aa07148; 22 Nov 94 11:32 EST
Date:     Tue, 22 Nov 94 16:30:33 GMT
From:     "John R. Anderson" &lt;jra@arl.mil&gt;
To:       CAD-Beta@arl.mil
Subject:  Closed Bug#168: mged NMG editing
Message-ID:  &lt;9411221130.aa06788@wolf.arl.mil&gt;

<p>

<p>
	Using a method suggested by Mike Muuss, I have added a
rudimentary sketch capability to MGED. This has been accomplished
by including NMG's to the "make" command, allowing the creation
of a nearly empty NMG. The only geometry in an NMG created this
way is a single "wire" loop, consisting of a single edge that runs
to and from the same vertex.
	New menu items have been added to the NMG solid edit menu
that allow splitting edges.  The user may select "split edge" and
then use the mouse to indicate where the new vertex should be
positioned. The user may continue to build the sketch by repeatedly
selecting points with the mouse or using the "p" command.
	There is also a "delete edge" menu item that will delete the
currently selected edge, and a "move edge" menu item to allow moving
an edge perpendicular to its length.
	Note that these menu items will not currently work for the
typical NMG solid, but only "wire" loops. The "move edge" will
work for simple NMG solid objects.
	The sketch is mantained always as a loop, and when the user
is satisfied with the sketch, the "extrude loop" menu item may be
selected to produce an extruded solid. This works similar to other
solid editing items as the user may use any number of mouse point
selections or "p" commands to produce different extrusions until
the desired effect is accomplished.  Then the usual "ACCEPT" or
"REJECT" menu item is selected.

<p>
			-John
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa29330; 2 Dec 94 3:07 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa16448; 2 Dec 94 1:45 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa16446; 2 Dec 94 1:40 EST
Date:     Fri, 2 Dec 94 6:34:05 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
Subject:  4.3 Beta2
Message-ID:  &lt;9412020134.aa26885@wolf.arl.mil&gt;

<p>

<p>
Based upon the feedback we have received since the Beta test period has
started, a number of small but important improvements have been made,
primarily in the realm of portability, but also some new features.

<p>
The most notable new features are courtesy of Timothy Smith and the
crew at Sun Microsystems, who have contributed a really nice X11 module
for LIBFB which supports 24, 8, and 1 bit visuals.  They have also
contributed improved Sun XGL support for MGED which is compatible with
Solaris and can take advantage of Sun graphics accelerator hardware.

<p>
Sun is working hard to make their systems run BRL-CAD "as well as an SGI
does".  While they still have some work to do in the area of graphics
performance, their RT performance is astonishingly good.  In my very
rough initial testing, a 50 MHz (each) 4-CPU Hyper-SPARC SS10BSX system
with Solaris 2.4 (summary RTFM=178.69) ran more than 2.5 times as fast
as a 1-CPU 150 MHz R4400 based SGI Indigo**2 with Irix 5.2 (summary
RTFM=63.89).  More than just MegaHertz matters!

<p>
As before, the beta test sources can be found on host FTP.ARL.MIL
in the directory "brl-cad/Rel4.3/src":

<p>
-r--r--r--   1 mike     graphics 7233902 Dec  2 00:32 cad4.3.tar-a.Z
-r--r--r--   1 mike     graphics 2146289 Dec  2 00:33 cad4.3.tar-b.Z
-r--r--r--   1 mike     graphics 1706300 Dec  2 00:33 cad4.3.tar-c.Z
-r--r--r--   1 mike     graphics 2136811 Dec  2 00:34 cad4.3.tar-d.Z
-r--r--r--   1 mike     graphics 1007393 Dec  2 00:35 cad4.3.tar-e.Z
-r--r--r--   1 mike     graphics  744433 Dec  2 00:35 cad4.3.tar-f.Z
-r--r--r--   1 mike     graphics 1893163 Dec  2 00:36 cad4.3.tar-g.Z

<p>
Please report any difficulties you might encounter, using the
"cadbug.sh" script.

<p>
	Enjoy!
	 -Mike
<hr>
<hr>
Received: from wharf.arl.mil by wolf.arl.mil id aa05844; 2 Dec 94 12:32 EST
Received: from Sun.COM by wharf.arl.mil id aa12527; 2 Dec 94 12:22 EST
Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
	id AA18655; Fri, 2 Dec 94 09:21:53 PST
Received: from spdev.East.Sun.COM (spdev-gw.East.Sun.COM) by East.Sun.COM (4.1/SMI-4.1)
	id AA26888; Fri, 2 Dec 94 12:21:48 EST
Received: by spdev.East.Sun.COM (5.0/6.1-spdev1) id AA09137; Fri, 2 Dec 1994 12:20:55 +0500
From: Timothy G Smith - Special Projects &lt;tgsmith@sun.com&gt;
Message-Id: &lt;9412021720.AA09137@spdev.East.Sun.COM&gt;
Subject: Re: 4.3 Beta2
To: Mike Muuss &lt;mike@arl.mil&gt;
Date: Fri, 2 Dec 1994 12:20:54 -0500 (EST)
Cc: CAD@arl.mil
In-Reply-To:  &lt;9412020134.aa26885@wolf.arl.mil&gt; from "Mike Muuss" at Dec 2, 94 06:34:05 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1197

<p>
If I'm not mistaken,  Mike Muuss said:
&lt; Date:     Fri, 2 Dec 94 6:34:05 GMT
&lt; From: Mike Muuss &lt;mike@ARL.MIL&gt;
&lt; To: CAD@ARL.MIL
&lt; Subject:  4.3 Beta2
&lt;
&lt; Sun is working hard to make their systems run BRL-CAD "as well as an SGI
&lt; does".  While they still have some work to do in the area of graphics
&lt; performance, their RT performance is astonishingly good.  In my very
&lt; rough initial testing, a 50 MHz (each) 4-CPU Hyper-SPARC SS10BSX system
&lt; with Solaris 2.4 (summary RTFM=178.69) ran more than 2.5 times as fast
&lt; as a 1-CPU 150 MHz R4400 based SGI Indigo**2 with Irix 5.2 (summary
&lt; RTFM=63.89).  More than just MegaHertz matters!

<p>
Thanks for all of the nice words, Mike.

<p>
One minor correction:  The system you have has 4 SuperSPARC processors,
not 4 hyperSPARC processors.  The hyperSPARC was just recently
introduced and only FCSed yesterday.  It is a 100MHz part that is
roughly a third faster (according to the SPEC numbers) than the
SuperSPARC processors you currently have.  I have not had a chance to
benchmark the hyperSPARC yet but hope to soon.  The hyperSPARC has a
smaller cache than the SuperSPARC so it will be interesting to see how
it compares on the RT benchmark.

<p>

<p>
--tim
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa13812; 9 Nov 94 18:10 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa02530; 9 Nov 94 17:03 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa02367; 9 Nov 94 16:52 EST
Date:     Wed, 9 Nov 94 16:45:42 EST
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       cad@ARL.MIL
Subject:  BRL-CAD 4.4 and FASTGEN
Message-ID:  &lt;9411091645.aa13033@wolf.arl.mil&gt;

<p>

<p>
	A new release of BRL-CAD is coming soon, so for those of you
who have been using FASTGEN, here is an update on what to expect in the new
release.

<p>
	PATCH-G has been updated to take advantage of the new NMG
capabilities in BRL-CAD. Plate mode components in FASTGEN are described
as triangular faces with a specified thickness.  These triangles are
converted to NMG triangular faces and then extruded by the thickness of the
plate to create a true solid in BRL-CAD. Previously, these components were
converted by building an ARB6 (an extruded triangle) for each triangle in
the plate mode object. This resulted in cracks or overlaps where two adjacent
triangles were not coplanar. The new method extrudes the entire surface of
triangles to produce a single solid with no cracks or overlaps for the plate
mode object. Volume mode component in FASTGEN may also be described using
triangular faces. These are also converted to BRL-CAD NMG solids. There is a
user option to have the final BRL-CAD NMG solids written to the database as
polysolids rather than as NMG's. The NMG's are more flexible and carry more
information about the solid (topology as well as geometry), but for most
current vulnerability analyses the polysolids will be adequate. The remainder
of the FASTGEN object types are converted to corresponding BRL-CAD solids
in the same manner as the previous release.

<p>
	A FASTGEN4 to BRL-CAD converter has been added to the BRL-CAD
package. This code was described in an earlier note to this list. It
converts the new NASTRAN-like FASTGEN4 to BRL-CAD in a manner similar
to the PATCH-G converter.

<p>
	FASTGEN users reading this should also be aware of the BURST code
written by Gary Moss. This code produces shotline output for parallel ray
grids or for bursting (disribution of rays emanating from a single point).
This output may be used with the Air Force Point Burst Damage Assessment
Model (PDAM), and is is in a format suitable for filtering to an unformatted
file to mimic FASTGEN output.  Leonard "Bud" Bruenning &lt;bruennin@uv3.eglin.af.mil&gt;
is the keeper of the BURST code if you need more information.

<p>
	There is also an RTG3 code to produce parallel ray shotlines from a
BRL-CAD model in a form like that produced by the old GIFT code (3 components
per line). This shotline output is compatible with the COVART family of
vulnerability anaysis codes.

<p>

<p>
			-John

<p>

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058
<hr>
<hr>
Date:     Thu, 10 Nov 94 13:37:41 EST
From:     "John R. Anderson" &lt;jra@arl&gt;
To:       J. Terrence Klopcic &lt;klopcic@arl.mil&gt;
cc:        phd@arl.mil, lex@arl.mil,
          mike@arl.mil, jehunt@arl.mil, jnw@arl.mil,
          jake@arl.mil
Subject:  Re:  BRL-CAD 4.4 and FASTGEN
Message-ID:  &lt;9411101337.aa27289@wolf.arl.mil&gt;

<p>
&gt; John,
&gt;
&gt; Great work.  As someone who is constantly representing BRL-CAD to
&gt; the outside world (JTCG, TILV, etc., etc.), I really appreciate
&gt; the importance - political as well as technical - of your
&gt; accomplishment.  Thanks for making my job much easier.

<p>
	My pleasure, Thanks!

&gt; I had a thought (unaccustomed as I am ....):  In the process of
&gt; bisecting the "cracks" or "overlaps" between plates, you had to
&gt; determine the intersection line between the plates on the top and
&gt; bottom surfaces, right?  That means that - at that time - you new
&gt; where the edges of the plates were.  Well, I would like to point
&gt; out that lots of people would really like the ability to determine
&gt; just that: folks who are trying to propagate ballistic shock,
&gt; folks that are trying to determine the extent of panels for blast
&gt; loading, folks that are trying to establish zones for combined
&gt; blast-fragment synergistic effects, etc.  Is there potential
&gt; spin-off here?

<p>
	Maybe, but let me give you a few more details.
Then you can tell me if we are talking about the same thing.

<p>
The plate mode objects in a FASTGEN description are typically described
as a series of triangles, each with an assigned thickness.  This method
is normally used for shapes that cannot be described any other way in
FASTGEN. Things like aircraft skin, tank turrets, ... anything that is
not a box, cylinder, cone, sphere, ellipsoid, or torus. In the previous
version of the "patch-g" converter, each triangle was converted to an
individual solid by extruding each triangle individually. The resulting
solids produced the  "cracks" or "overlaps" with their neighbors.
The method I used, does not require bisecting these  "cracks" or "overlaps".
I combine all the triangles from one component into a single NMG surface
(the surface consists of the triangles from the FASTGEN component). I then
make a copy of this surface, calculate new plane equations for triangular
faces (translating each plane by the assigned thickness in the appropriate
direction), and (using the new plane equations) calculate new vertices
at the intersection of the faces (much detail omitted here). More faces
are added to connect the outer edges of the original surface and the
extruded copy, resulting in a true NMG solid.

<p>
So, the  "cracks" or "overlaps" had been occurring where two triangles of
a plate mode component adjoined. This is just a artifact of the method used
to describe the component (triangular facets used to approximate smooth
surfaces). I doubt that is what you are looking for.

<p>
However, the new NMG capability in BRL-CAD may be what you want. As well
as storing geometry, the NMG objects contain topology as well. If I have
a face of an NMG object, I can easily get a list of its edges and vertices.
It is simple to go on from there to find neighboring faces and their
edges and vertices. The entire object can be traversed in this way.
Also, edges in an NMG object are labelled as "real" if they represent
real edges and are not just the result of tessellation. For example,
a pilots head might be described as an ellipsoid. Currently, if this is
converted to an NMG object, it will be approximated by a series of facets.
None of the edges in this NMG will be flagged as "real" edges. If, however,
his head was described as a box, all the edges in the corresponding NMG
would be "real".

<p>
Just to be sure you are aware of what's coming, we are currently working
to extend NMG objects to allow TNURB (Trimmed Non-Uniform Rational B-spline)
faces instead of just planar faces. When this is complete, tank turrets,
a/c skin, (and pilot heads, too) may be described without approximating
facets.

<p>

<p>
	I think I got carried away with this response, but does this
sound like what you are looking for??

<p>

<p>

<p>
				-John

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa13513; 7 Sep 94 9:20 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab16187; 7 Sep 94 9:15 EDT
Received: from worm.arl.mil by WALRUS.ARL.MIL id aa16049; 7 Sep 94 9:10 EDT
Date:     Wed, 7 Sep 94 13:00:55 GMT
From:     "Jill H. Smith, Ch., Vuln. Meth. Br." &lt;jill@ARL.MIL&gt;
To:       cad@ARL.MIL
Subject:  [John R. Anderson: FASTGEN4 to BRL-CAD Progress]
Message-ID:  &lt;9409070900.aa02285@worm.arl.mil&gt;

<p>

<p>

<p>
	The JTCG/ME ATV Subgroup task to develop a FASTGEN4 to BRL-CAD geometry
translator has been completed.  This capability will be distributed in the
next BRL-CAD release.

<p>
	The FASTGEN4 CHEX1, CQUAD, and CTRI elements (in plate-mode or volume-mode)
are converted to the users choice of BRL-CAD NMG's or polysolids.  In rare cases,
the method used to create NMG's from plate-mode elements fails. When this happens,
the converter makes a second attempt to convert the component by reverting back
to the methodology used in earlier "patch-g" converters, i.e., each triangle in
the plate-mode object is converted to an "arb6".  CCONE1 and CCONE2
elements are converted to BRL-CAD "gentgc" solids with internal "gentgc" solids
subtracted if necessary. CSPHERE elements are converted to BRL-CAD "genell" solids
with interior "genell" solids subtracted for the plate-mode cases. CHEX2 elements
are converted to BRL-CAD "arb8" solids.  CLINE elements are converted to BRL-CAD
"gentgc" solids with inner "gentgc" solids subtracted in the plate-mode cases.
CLINE elements that share endpoints with other CLINE elements in the same component
are connected by spheres ("genell" solids) at the common endpoints (again, with
interior spheres subtracted in plate-mode).  These "genell" solids have the same
radii as the connecting CLINE elements.  HOLE and WALL elements are handled by
region subtraction in BRL-CAD.

<p>
	Unique names are assigned to all the resulting BRL-CAD components. If
the FASTGEN4 model includes $NAME records, that text information is used
to build a name within the constraints of the BRL-CAD name-space. If no $NAME
record is found for a component, a name is constructed from the group and
component numbers.  The user may specify a "-w" flag on the command line to
get a warning for every component that does not have a $NAME record.  The
components are grouped according to the FASTGEN4 "group" number, and a top
level group named "all" (containing all the other groups) is created.

<p>
	BRL-CAD "region id" numbers are constructed as the FASTGEN4 "group
number" times 1000 plus the FASTGEN4 "component number".

<p>
	A BRL-CAD manual page has been prepared and is included in the
BRL-CAD distribution along with the FASTGEN4 to BRL-CAD converter ("fast4-g").

<p>
	This converter has been tested using two models received from Mr.
Marty Lentz - the F4E and the MH60.  Of the 954 components in the F4E, 918
are converted on the first try and an additional 32 are converted on the
second try (using "arb6" solids). This leaves 4 components that failed
to convert.  The MH60 has 1016 components, 1006 converted on the first
pass and 8 more converted as collections of "arb6" solids. Two components
of the MH60 failed to convert. All six of the components that failed to
convert can be attributed to errors in the FASTGEN4 model.  The original
MH60 FASTGEN4 model was modified during the development of this converter
to eliminate some of the FASTGEN4 errors, and the results quoted are for
the modified model. The F4E was not modified in any way.

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa02300; 7 Dec 94 14:58 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa23896; 7 Dec 94 14:02 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa23640; 7 Dec 94 13:50 EST
Date:     Wed, 7 Dec 94 13:40:26 EST
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       browder jr &lt;browder@use1.eglin.af.mil&gt;
cc:       cad@ARL.MIL
Subject:  Re:  brl-cad 4.3
Message-ID:  &lt;9412071340.aa01133@wolf.arl.mil&gt;

<p>
The HyperText Markup Language (HTML) files may be viewed using NCSA Mosaic.
Available via FTP from:
	ftp.ncsa.uiuc.edu
or unofficial mirror sites:
----------------------------------------------------------------------------
USA:
  site:     sunsite.unc.edu
  location: /pub/packages/infosystems/WWW            (all versions)
Australia:
  site:     miriworld.its.unimelb.edu.au
  location: /pub/clients/                            (all versions)
Europe:
  site:     ftp.luth.se
  location: /pub/infosystems/www/ncsa                (all versions)

<p>
  site:     ftp.sunet.se
  location: /pub/mac/Mosaic                          (mac version)
            /pub/pc/windows/www/Mosaic/              (pc version)
            /pub/www/Mosaic                          (X version)

<p>

<p>
		Hope this helps,
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa07535; 7 Dec 94 22:20 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa29315; 7 Dec 94 22:17 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa29313; 7 Dec 94 22:16 EST
Date:     Thu, 8 Dec 94 3:06:03 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       "Joseph E. Meier" &lt;jem@sonic.bruker.com&gt;
cc:       CAD@brl.mil
Subject:  Re: tutorial for NMG
Message-ID:  &lt;9412072206.aa07284@wolf.arl.mil&gt;

<p>

<p>
Hi Joe -

<p>
In your letter you didn't mention which version of BRL-CAD you are
working with.  That makes something of a difference.  If you are running
Release 4.0, 4.1, or 4.2, the NMG support is not very robust.

<p>
As of now, there are very few NMG-related commands in MGED, although
those few deliver a lot of functionality.  You can use MGED's built-in
"help" command to give you a 1-line summary of each:

<p>
ev		evaluate combinations into polygons for display.
facetize	evaluate region into an NMG solid, and store in database.

<p>
In addition, the "make" command will now (in 4.3beta2) allow you to
create an NMG which is a loop of a single vertex and a single edge
("make name.s nmg"), which you can then select for solid editing ("sed
name.s").  Using the solid editing menu, you can then use the "pick
edge", and "split edge" items to sketch out a 2-D curve in the plane of
the current view.  Select another view, pick "extrude loop" from the
menu, and then *voila!*, you have built yourself an NMG solid! The
extrusion can also be controlled via the "p" command, where you specify
the XYZ coordinates of a point to lie on the plane of the extruded face.

<p>
There are a few other commands that interact with the NMG support, such
as "fracture", which can be useful for debugging, and "debugnmg".

<p>
For a fascinating visual display of how the NMG boolean library
implementes the "ev" command, say "debugnmg 3" before running the "ev"
command.

<p>
Suggestions for additional NMG support in MGED are welcomed.  I've got
plenty of ideas, myself. Contributions of code implementing those
suggestions are even more welcome!  :-)

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa11749; 8 Dec 94 5:12 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa02186; 8 Dec 94 4:38 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa02182; 8 Dec 94 4:31 EST
Date:     Thu, 8 Dec 94 4:29:38 EST
From:     "Lee A. Butler" &lt;butler@ARL.MIL&gt;
To:       browder jr &lt;browder@use1.eglin.af.mil&gt;
cc:       cad@ARL.MIL
Subject:  Re:  brl-cad 4.3
Message-ID:  &lt;9412080429.aa11458@wolf.arl.mil&gt;

<p>
&gt;a quick qestion for a novice -- what do i need to use the "html" files?
&gt;
&gt;(and is there a freeware source on line?)

<p>
The most popular browser for WWW/html documents is "Mosaic" available from
ftp.ncsa.uiuc.edu.  It requires motif to compile, or you have to trust
the binary they have out for ftp (ugh).

<p>
If you don't have motif and don't want to trust the NCSA binary out for ftp
(and why should you?), I'd suggest getting a copy of "chimera" from
ftp.cs.unlv.edu.  It only requres X and the athena widget set to compile.

<p>
Lee
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa25101; 11 Sep 94 11:26 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa20833; 11 Sep 94 10:44 EDT
Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa20806; 11 Sep 94 10:32 EDT
Received: from rumors.delta.edu by wharf.arl.mil id aa02857; 11 Sep 94 10:21 EDT
Received: by rumors.delta.edu (AIX 3.2/UCB 5.64/4.03)
          id AA05419; Sun, 11 Sep 1994 10:15:29 -0400
Date: Sun, 11 Sep 1994 10:15:29 -0400
From: laut@rumors.delta.edu
Message-Id: &lt;9409111415.AA05419@rumors.delta.edu&gt;
To: nemiroal@fenris.com, phil@ARL.MIL
Subject: Re:  Another BRL 4 Linux question.
Cc: cad@ARL.MIL

<p>

<p>
| Yes.  There is an enhanced version of MGED known as XMGED that requires
| Motif in order to compile and run.  Regular MGED continues to be available
| and supports X based on libx11 alone, but has a much more primitive
| interface.  We may someday build an XMGED that does not depend on Motif,
| depending on how users like the current one and where they think it should
| go (e.g. Mike's group is playing with a Tcl/Tk MGED).

<p>
It -is- a nice feature of BRL-CAD that it does not entirely depend upon Motif
to work.  Some vendors (read DEC) still insist upon "nickel-and-diming" you
at every opportunity, and for awhile their Motif upgrade was big, BIG, $$$.
Although, in fairness, they have become more reasonable of late.

<p>
If applications such as XMGED become the norm, then it would be nice to see
BRL-CAD eventually adopt a standard metaphorically akin to LIBPKG which would
allow the utilities to support differing windows technologies (ie, plain X,
X-with-Motif, X-under-Windows, Windows-NT, etc).

<p>
Perhaps a better metaphor would be LIBFB instead of LIBPKG.  Actually, maybe
expanding LIBFB to include windowing might be a consideration.  Have LIBFB
return to the application the graphics ability of the "frame buffer," and there
decide whether or not to support a windowing option.  And, if selected, let
LIBFB absorb all of the hardware/vendor-dependent stuff.

<p>
Thoughts?

<p>
-Bill
<hr>
<hr>
Received: from wolf.arl.mil by wolf.arl.mil id aa04761; 21 Dec 94 11:03 EST
Date:     Wed, 21 Dec 94 15:57:44 GMT
From:     Paul Tanenbaum  &lt;pjt@arl.mil&gt;
To:       CAD-Beta@arl.mil
cc:       Chris Hunt &lt;cahunt@arl.mil&gt;
Subject:  Closed Bug#249: NIRT needs LOS option added
Message-ID:  &lt;9412211057.aa04585@wolf.arl.mil&gt;

<p>

<p>
     I implemented a new output item called "scaled_los" to complement the
existing output item "los".  The values of these two output items are

<p>
    los		line-of-sight distance through the current partition,
		equivalent to (d_in - d_out).  This is unchanged from
		previous versions of NIRT(1).

<p>
    scaled_los	scaled line-of-sight distance through the current
		partition, the product of los and the region's
		solidity (also known variously as its percent LOS,
		thickness factor, and volumetric percentage of
		material (!)).  This is a brand-new feature.

<p>
I would have called the new output item "weighted_los", but apparently
that might have caused confusion in the MUVES community, where weighting
an LOS means multiplying it by the region's solidity AND ITS DENSITY.
     Of course, to use this new output item one must tailor the output
formats as explained in the man page nirt.1.
     Paul

<p>
<hr>
<hr>
Date:     Wed, 21 Dec 94 20:18:54 GMT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       Mike Muuss &lt;mike@arl.mil&gt;
cc:       CAD@ARL.MIL
Subject:  Re: BRL-CAD Release 4.3beta3 now available
Message-ID:  &lt;9412211518.aa11211@wolf.arl.mil&gt;

<p>

<p>
Those of you trying to compile the 4.3beta3 release on IRIX 5.2 will
need to modify the Cakefile.defs file.  There are bad side effects
from using -Wl,-w2 -- if *any* warning message is printed by the loader,
it seems to abort the load.  This wasn't the intention.

<p>
For the time being -Wl,-w1 seems to be having the desired effect.

<p>
The whole "-w" option on LD is not documented by SGI at all, but their
Hotline suggested using it in place of the documented "-S" option,
which does not work.  Sorry about the blundering around in the dark.

<p>
	Best,
	 -Mike
<hr>
<hr>
Date:     Wed, 21 Dec 94 21:28:46 GMT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       ACST@arl.mil
Subject:  Irix 5.2 -Wl,-w values
Message-ID:  &lt;9412211628.aa11380@wolf.arl.mil&gt;

<p>

<p>
Per Chris Johnson:

<p>
Hello, here is the exhostive 0-15 on -w options.
only the valuses 1-3 are acceptable.
1 = surpress all warnings plus all errors (default)
2 = error off on any warning or error
3 = surpress all warnign s plus all errors AND error off on any warning or
error.

<p>
Looks like -w1 is the best we can do, then.

<p>
	-Mike


<p>
<hr>
<hr>
Date:     Thu, 22 Dec 94 3:02:13 GMT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       acst@arl.mil, Lex@arl.mil, Jill@arl.mil, PHD@arl.mil, PJT@arl.mil,
           Davisson@arl.mil, WM@arl.mil, GDurf@arl.mil, Moss@arl.mil,
           BParker@arl.mil
cc:       wbowman@arl.mil, gillis@arl.mil, reed@arl.mil, CJohnson@camelot.com
Subject:  No #elif, please
Message-ID:  &lt;9412212202.aa16596@wolf.arl.mil&gt;

<p>

<p>
When writing portable BRL-CAD code, please do not use the #elif
preprocessor directive.  This is new with ANSI C, and can not be
processed by earlier, non-ANSI compilers.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa10955; 27 Dec 94 15:54 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa03991; 27 Dec 94 15:08 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa03989; 27 Dec 94 15:07 EST
Date:     Tue, 27 Dec 94 19:58:06 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       merlin &lt;merlin@neuro.usc.edu&gt;
cc:       cad@brl.mil
Subject:  Re: BRLCAD for US citizen employed in United Kingdom
Message-ID:  &lt;9412271458.aa07806@wolf.arl.mil&gt;

<p>

<p>
AJ wrote -

<p>
&gt; I will be traveling to work in the United Kingdom (University College
&gt; London) for two years beginning in May 1995.  I gather it would not be
&gt; proper to just take a take of the current version of BRLCAD with me to
&gt; England.  I also understand it would not be proper to just ftp a new
&gt; copy (without some prior formal arrangement for permission acquire new
&gt; versions by anonymous ftp and decrypt the package in another country).
&gt;
&gt; Approaching the British Foreign Office to obtain a copy of BRLCAD for
&gt; a United States national seems a bit awkward.  Nevertheless, it may be
&gt; the proper approach to obtaining permission to use BRLCAD in England.
&gt;
&gt; So, I would appreciate advice about the appropriate procedure to follow
&gt; to obtain BRLCAD for use in England.

<p>
Congratulations on your foreign appointment!  UCL is a cool place, and
I'm sure you will have a splendid time there.

<p>
Thanks for asking what the proper procedure is.  It is no longer
necessary to involve the Foreign Office for overseas distribution.
Fortunately we were able to eliminate that step many years ago.

<p>
BRL-CAD agreements are executed either by (a) a private individual,
when their use is for personal use, or (b) a corporation or institution.
In your case, I believe that your current agreement is executed by
your current University.  Since you are temporarily changing
affiliations, simply fill out and return an agreement through UCL, and
rest easy.

<p>
Since you already have the BRL-CAD materials, and UCL is (will be) a
registered site, you are free to take whatever materials you like along
with you in whatever manner is most convenient to you.  Your associates
here in the States can continue to work with your original set.

<p>
That's all there is to it!  Hopefully sending in the one form won't be
much of an inconvenience to you.  It will be a big help to us!

<p>
THE BIG PICTURE

<p>
I was recently informed that BRL-CAD is the U.S. Army's #1 "Technology
Transfer Product".  It's also the only one that is still available
without charge to any who want it.  These are both points of pride for
those of us who developed it.

<p>
In this time of downsizing, it is important that the usefulness of our
BRL-CAD work continue to be recognized, to help us protect our funding
line. The "survey" form that you return with your BRL-CAD agreement is
our primary source of documentation to support our position.

<p>
Over the years I have worked to streamline the agreement process as much
as possible.  I like to believe that the procedure and forms we have
been using since Release 4.0 started are not overly burdensome. As we
come up on Release 4.4 Mary Monk and I will be working on an improved
version of the forms and procedures to further streamline distribution
to foreign sites.

<p>
My thanks to all of you, the BRL-CAD users, for making BRL-CAD a success!

<p>
	Happy Holidays!
	 -Mike Muuss

<p>
<hr>
<hr>
Received: from wolf.arl.mil by wolf.arl.mil id ab19080; 23 Dec 94 19:47 EST
Date:     Sat, 24 Dec 94 0:38:55 GMT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       Cad-Beta@arl.mil
Subject:  per-vertex surface normals
Message-ID:  &lt;9412231938.aa19032@wolf.arl.mil&gt;

<p>

<p>
This evening, while tracking a performance issue on the Sun XGL display
manager relating to drawing speed of dot-dashed lines in MGED, I
added two new options to the "e" and "ev" command in MGED:

<p>
-s	Draws all subtraction and intersection solids with solid lines,
	rather than using the usual dot-dash pattern.

<p>
-v	When used with EV, shade polygons with per-vertex surface normals,
	rather than flat-shading them with the face normal.
	This makes much "prettier" looking curved shapes, for
	presentations.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from wolf.arl.mil by wolf.arl.mil id aa25349; 27 Dec 94 22:53 EST
Date:     Wed, 28 Dec 94 3:52:41 GMT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       CAD-Beta@arl.mil
Subject:  Closed Bug#65: libfb/if_remote fails to implement rem_setcursor()
Message-ID:  &lt;9412272252.aa25329@wolf.arl.mil&gt;

<p>

<p>
I don't know why the remote framebuffer library never had a routine
to support remotely defining the shape of the cursor.  However, Sue
Coates' bug report is quite accurate -- it doesn't work. I defined a new
kind of remote framebuffer PKG to implement the missing routine:
MSG_FBSETCURSOR.

<p>
In order to prevent having a new LGT get stuck waiting forever for
the MSG_RETURN package when using an old RFBD framebuffer server,
I made if_remote.c send the request with flag MSG_NORETURN.  This way
old framebuffer servers will log the message "pkg_dispatch: no handler
for message type 131, len 20" and harmlessly ignore it, without hanging
the user application (like LGT).

<p>
libfb/if_remote.c revision 9.20, libfb/pkgtypes.h revision 9.4,
fbserv/fbserv.c revision 10.7, fbserv/fbserv.h revision 10.3,
rfbd/rfbd.c revision 10.7.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa24466; 27 Dec 94 21:47 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab07932; 27 Dec 94 21:20 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id ab07826; 27 Dec 94 21:16 EST
Date:     Wed, 28 Dec 94 2:09:39 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       Bob Strausser &lt;strssr@ARL.MIL&gt;
cc:       Dane Kottke &lt;dkottke@sanders.com&gt;, cad@ARL.MIL
Subject:  Re: XMGED editing of NURBs
Message-ID:  &lt;9412272109.aa22021@wolf.arl.mil&gt;

<p>

<p>
Bob wrote -

<p>
&gt; As far as I am aware, there is no current editing capability in either
&gt; MGED or XMGED for NURBS.  I believe the current beta release does permit
&gt; some editing of an NMG but not NURBs.

<p>
In the Beta release (BRL-CAD Release 4.3), there exists some modest MGED
editing capability for *both* planar NMGs and the existing NURBS solids.
In the case of NURBS solids, the editing is restricted to moving control
points around using the mouse.  This is probably acceptable for simple
"by eye" touch-up, but is a far cry from "sophisticated" B-spline
editing.

<p>
	Best,
	 -Mike
<hr>
<hr>
<a href="mailto:mike@arl.mil">
  &lt;<em> mike@arl.mil </em>&gt;
  </a>

<br>
<a href="index.html"> Release notes for other versions of BRL-CAD </a>
</body>
